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ABSTRACT 
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development life cycle (SDLC). The requirements for the system are obtained, and the 
database and application are designed and implemented. Paradox is used for the database 
management system software. Special issues like training, security, conversion and 
maintenance are taken into consideration. 

The result of this thesis is a functional application named "SPAS" (Shipboard 
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L INTRODUCTION 


A. OBJECTIVE 

This thesis designs and implements a database system for the Hellenic Navy ships. 
The purpose of the system is to support all the administrative activities of the personnel 
assigned onboard. The implementation of the database system would greatly reduce the 
work hours spent on specific administrative tasks that are instrumental in accomplishing 
Hellenic Navy ships’ principal tasks and maintaining an efficient operational level. The 
database design takes into consideration the Hellenic Navy ships’ functional requirements. 
The primary function of the database system is to maintain the records of necessary 
personnel and other relevant information. From this database standard reports are 


generated, and ad hoc queries and reports are created. 


B. BACKGROUND 

In every battle ship the personnel should be organized in such a way that the ship 
can provide a variety of functions and operate under different situations in different 
environments. These functions are performed by the persons serving on the ship. The 
management of this personnel organization 1s a difficult and time-consuming job in terms 
of personnel data entry, maintenance of manually kept forms, determination and allocation 
of duties and handling personnel requests. Furthermore, the large volume of daily, weekly 


and monthly reports required either for submission to the higher command or for the 


ship's internal use, makes the personnel administration job very difficult. In addition, the 
command needs help in making decisions about subjects of an administrative nature: for 
example, having people process data in order to propose a suggestion Is a time consuming 
task and might result in inaccurate and unreliable information. 

The ship consists of departments which are managed by the department heads, and 
divisions which are managed by the division officers. In the Hellenic Navy, only 
commissioned and non-commissioned officers serve on a permanent basis while seamen 
serve for a short standard period of time. Crewmember changes are based on annual 
occurrences. Seamen changes are based on the time served. From time to time projection 
tables must be sent to the Navy training centers for future needs of seamen assignments. 
The new seamen must first obtain training for special duties; then they have to be 
qualified by the division officer or the department head; finally they may get some 
additional training while they serve. 

To help the reader in what follows, the following are some brief explanations of 
terminology as applied in the Hellenic Navy: 

Pont Duty Station is the assigned position in which every crewmember has to work 
while in port. 

Fitness Evaluation is a compulsory procedure for officers up to the rank of 
Lieutenant and Petty Officers up to 40 years old, in which they must pass an annual 
physical fitness test. 

Promotion \s a promotion in rank. Seamen do not receive promotions, only Officers 


and Petty Officers do. The promotion can never exceed the following higher rank. 


Disciplinary report — the crewmember's offense, apology, and punishment. 
A record of the date, nature of event, facts and everything related to the offense is kept. 

Crew division systems is how the crew is divided to perform onboard activities. 
There are two crew division systems. The first is called "Half Crew Division System" 
under which each crewmember is scheduled to work 6 hours and rest for 6 hours. The 
second work schedule is called "One Third Crew Division System" and has shifts of 4 
hours on and 8 hours off. The decision to adopt either one of the systems depends on the 
type of ship's operations being conducted. 

Leave designates the type of leave given to crewmembers. In addition, seamen 
serving onboard a ship have right to the so-called "sea duty leave". 

On the Job Training Evaluation (OJT) applies to Officers, Petty Officers and seamen 
who are all subject to OJT Evaluation. The evaluation occurs at regular intervals and is 
set by the Department Head or the Division Officer. If a member changes his position, 
the OJT Evaluation is automatically performed. 

A bandon Ship Station is the preassigned station in which every crewmember has 
to proceed once the order "Abandon Ship" has been given. 

The Armed Security Group is composed of an Officer as the leader and several 
Petty Officers and sailors; it has the predefined task of defending the ship against terrorist 
attacks or intruders. 

Change in Command 1s a change of role or duty in the Department or the Division 
for an Officer or a Petty Officer. 


Mooring, Anchoring, and Towing station are the areas where all personnel are 


assigned to be while mooring, anchoring or towing Is occurring. 

Training is the term that covers the training received in a school by an Offficer, 
Petty Officer or seaman. 

Air controller is an Officer or Petty Officer whose duty is to control all aircraft 
cooperating with the ship. 

Alert Station is the pre-assigned position of each crewmember under alert 
conditions. 

Replenishment at Sea Station is the station to which a specially trained team, led 
by an officer, proceeds when refueling at sea. The task of the RAS team is to take the 
necessary actions until refueling is over. 

XO's Daily Report Division is the division system in which crewmembers are 


gathered during the XO's daily morning report. 


C. METHODOLOGY 

There are different methodologies for developing systems. The process that will be 
followed in this thesis captures the essence of most development methodologies. The 
fundamental phases are: 

° Definition phase: 

During the definition phase, the tasks are to form the working team, define 

the problem, establish the scope, and access feasibility issues. 

° Requirements phase 


During the requirements phase, the tasks are to create the user's data model, 


determine the update, — and control mechanisms, as well as the functional 
components of the application, interview the users, and use prototypes to help determine 
user requirements. 
° Evaluation phase 
During the evaluation phase, the tasks are to select the system's architecture, 
and reassess feasibility issues. 
° Design phase 
During the design phase, the tasks are to develop the database design and the 
application design. The database design consists of structuring the relations, and 
establishing the relationships among them. The application design, deals with the design 
of the menus, reports, and forms as well as to specify update, display, and control 
mechanisms. 
. Implementation phase 
During the implementation phase, the tasks are to construct the database, build 
the application, and install it. 
This System's Development Life Cycle was utilized in the development of the Shipboard 


Personnel Administration System (SPAS) of this thesis. 


D. CHAPTER OUTLINE 
The thesis is organized as follows: 
Chapter II is a general description of the database development process. It reviews 


database concepts, and describes the database development phases. These phases, the 


requirements analysis and specification, the design, and the implementation, are detailed 
in the following chapters. 

Chapter III is the requirements analysis of the system. The operating environment 
is studied by means of the user's descriptive list of requirements for the system's 
functionality, data manipulation and production of specific information. The requirements 
and accompanied entity-relationship data flow diagrams are provided. The chapter 
concludes with a description of the requirements specifications as they pertain to data, 
hardware and software issues. 

Chapter IV describes the design process followed in developing the Shipboard 
Personnel Administration System ( SPAS ). The data and process models developed in 
the previous chapters are transformed into a relational and application design, respectively. 
The last section provides commentary about the data dictionary and its benefits to the 
database system design. 

Chapter V is a discussion of the final phases involved in developing the database 
system. These phases are the implementation portion of the data and process design and 
they include programming and planning for the system's implementation. 

Chapter VI deals with other important issues in developing the system such as 
testing, database security, personnel training, system conversion, maintenance and future 
upgrades. 

Chapter VII 1s the concluding chapter. It provides a short summary of the thesis 
and addresses future enhancements to the system developed. Also included are lessons 


learned in developing the system. 


Appendices A through I supplement the previously described text. The appendices 
are: Object Diagrams, Data Dictionary, Data Flow Diagrams, Relational Schema, 
Application Menus, Application Input Forms, Application Reports, System's Program and 


Code and Procedures for installing and operating SPAS, respectively. 


I. DATABASE DEVELOPMENT PROCESS 
In this chapter we will discuss basic database concepts as well as the database 
development methodology. Each step of the system's development methodology 1s 


described in some detail. 


A. DATABASE CONCEPTS 

The term database is subject to many different interpretations. It has been used to 
refer to everything from a collection of index cards to the volumes of data that a 
government collects about its citizens. In the following we will use this term with a 


specific meaning: A database is a self-describing collection of integrated records. 


1. A Database is Self-Descnbing 
In aadition to the user's source data, a database contains a description of its 
own structure. This description is called the data dictionary, and makes program/data 
independence possible. In that way, by examining the database itself, it's easy to 
determine its structure and its components; no external documentation of file and record 
formats 1s needed. Furthermore, when changing data in the database, we only need to 


make corresponding changes to the data dictionary. 


2. A Database is a Collection of Integrated Records 
As shown in figure 1, a database is more than a collection of files. It includes 
source data, a description of the database structure (data dictionary), and a description of 


the relationships among the records of the files (overhead data). The main difference 


between a database and a file processing system is that a database 1s able to store these 


relationships. 


files 
+ 


bytes data 
bits > or fields > records > dictionary database 


+ 
overhead 
data 


characters 





Figure 1: Hierarchy of data elements in database processing 


3. Components of a Database Processing System 
{ 
A database processing system has five components as shown in figure 2. 


Machine 
HARDWARE PROGRAMS DATA PROCEDURES PEOPLE 





Figure 2: Components of a database processing system 
These are hardware, programs, data, procedures and people. The most important 
components are the people and the data. The data contain all the useful information that 


people need to perform their tasks and complete their activities. 


B. DATABASE DEVELOPMENT METHODOLOGY 

The database development methodology described here consists of four phases: 
definition, requirements, evaluation, and design. Each phase consists of a number of 
tasks. 

During the definition phase the tasks are to form the working team, define the 
problem, establish the scope, and access feasibility issues. 

During the requirements phase, the tasks are to create the user's data model, as well 
as the functional components of the application. This is accomplished by interviewing 
the users, and using prototypes to help determine user requirements. 

During the evaluation phase, the tasks are to select the system's architecture, and 
reassess feasibility issues. 

During the design phase, the tasks are to develop the database design and the 
application design. The database design consists of structuring the relations, and the 
establishing relationships among them. The application design, deals with the design of 
the menus, reports, and forms. 

During the implementation phase, the tasks are to construct the database, build the 
application, and install it 


The requirements, design, and implementation are detailed in the following sections. 


C. REQUIREMENTS ANALYSIS / SPECIFICATIONS 
Accurately obtaining the system's information requirements from the potential users 


is essential. No system can be designed without first understanding the current process 


———_ 


intended for improvement. After the system's definition and primary analysis phase, 
where the general goals of the system are determined, the requirements phase follows. 
The purpose of this phase is to determine, as specifically as possible, what the system 
must do. There are two tasks in this phase: 

° develop a user's data model 

° determine the functional components of each application that will use the 


database 


1. Data Requirements 

During the data requirements phase, the major goals are to build a data model 
that documents the "things" that are to be represented in the database, to determine the 
characteristics of those "things" that need to be stored and to determine the relationships 
among them. The user's data model describes the objects that must be stored in the 
database, along with their structure and the relationships that they have with one another. 
The output of the data requirements phase is a statement of requirements. This statement 
can take a variety of forms: a verbal description; an entity-relationship and objects 
diagrams; one or more prototypes; or any combination of the above. 

The "things" that are represented in the database are referred to as either entities or 
semantic objects (in some cases just objects) depending on the modeling technique that 
the designer follows. In this thesis the semantic object model will be followed. 

A semantic object is a named collection of properties that sufficiently describes a 
distinct identity. Semantic object diagrams assist in the system analysis as well as the 


design phase. Some of the characteristics of semantic objects are: 


)] 


¢ the semantic objects are grouped into classes; each class has a distinctive 
name; classes are shown in capital letters 

. an object is a collection of properties with a sufficient description 

° objects represent distinct identities 

. the identities that the objects represent may or may not have physical existence 

Objects have properties that define their characteristics. These properties can be 
simple property, composite of a group of properties, or another object. An object can 
have single or multiple values. In a semantic object diagram, objects are shown in boxes; 
their name appears beneath or above the rectangle and properties are written inside the 
rectangle. The "MV" symbol next to a property declares that this property can have 
multiple values. The non-object properties have scalar values while the object properties 


are separate objects by themselves. Figure 3 shows a sample object. 


Property 1 
Property 2 ary 





Figure 3: Sample Object 


A property can take its ae from a set of possible values; this set 1s called the 
domain of the property. The domain gives both the physical and the semantic description. 
The physical description indicates the type of data, the length of the property and 
probably some restrictions or constraints that may apply to the property. The semantic 
description describes the function or purpose of the property. 

There are six categories of objects: 

a Simple Object 
A simple object contains only single-valued, nonobject properties. 
b. Composite Object 
A composite object contains one or more nonobject multivalued 
properties. 
c. Compound Object 
A compound object contains at least one object property. 
d. Association Object 
An association object is an object that relates two or more objects 
together and stores data that is peculiar to their relationship. 
e. Hybrid Object 
Hybrid objects are combinations of objects of other types. Most 
: frequently, hybrid objects involve the combination of a compound and a composite object 


in which the object property occurs in a composite group. 
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ff; Generalization and Subtype Objects 
Generalization and subtype objects are used to model generalization 
hierarchies. The generalization objects contain the generic description and indicate all 
possible alternatives for the object property, while the subtype objects inherit the 
properties from the generalization objects. 

The process for developing semantic objects can be done in either a top-down or 
bottom-up fashion. With the bottom-up approach, developers examine the application 
interface (primarily, reports and screen displays) and work backwards to derive the object 
structure. With the top-down design, the developer starts with the general idea of the 
goals of the application, involves the user in the development team and tries to determine, 
based on the nature of the objects and the application goals, what the properties are and 
how they are going to be stored in the database. The top-down approach requires more 
experienced developers and is risky. There is a significant chance that the imagination 
of even skilled database designers will be insufficient and that important properties or 
objects will be left out. 

Probably the best approach 1s the combination of both the top-down and bottom-up 
design. The best and the recommended way to proceed is to have in mind the 
application's conceptual idea, know the desired goals and the systems functionality, 
involve the user in the development phase and start work having the reports and the user's 


favorite interface "handy". Keep in mind that: "Data Modeling is an A nistic Process” 


14 


2. Data Dictionary 

A data dictionary or project dictionary as it is sometimes called, is a catalog 
of requirements and specifications for a new information system. (Witten, 1989, p.331) 
It provides definitions of all the data items in the database. During the definition phase, 
the analysts try to capture and store the data in the system, and find the inputs and 
outputs that the system will generate. These are represented with pictorial models such 
as data flow diagrams, relation diagrams, entities, data stores etc. The data dictionary 
expands this pictorial model and as a system analysis tool, captures the detailed 
requirements for every input, output and data store. The suggested approach for building 
the data dictionary should be in terms of “what” data are handled and not in terms of 


"how" data are presented or formatted. 


3. Process Requirements 

All systems process data to produce information and maintain stored data. These 
requirements should be logically modeled. In order to implement processes as programs, 
a process model is needed. A process model is a picture of the flow of data through the 
system and the processing that must be performed on that data. These processes interact 
or interface = ee another. These interactions take the form of data flows between 
processes and is the reason that they are sometimes called data flow models. One of the 
most popular system modeling tools for capturing process requirements is the data flow 
diagrams (DFDs). 

It should be emphasized that data flow diagrams are very different from flow charts, 


in the following ways: 


Js 


. Processes on a DFD can operate in parallel; several processes may be working 
simultaneously. This is a key advantage over flowcharts, which tend to show 
only sequences of processes 

¢  DFDs show the flow of data through a system unlike flowcharts that show 
Steps in an algorithm 

. DFDs can show processes that have dramatically different timing while 
flowcharts can't 


The following describes the basic components of a dataflow diagram. 


a. Internal or External Entity 
Every system has a boundary. This boundary is defined by the internal 
or external entities which provide the net input to the system and receive the net output 
from the system. The entities sometimes are called sources or destinations depending on 
whether they are inputs to the system or outputs from the system. Names and titles can 
be used to describe the label of the entities. Entities never interact directly with data 


stores, and relationships between entities are not modeled. 


b. Process 
The emphasis on any DFD is given to the processes, sometimes called 
activities. Processes transform inputs into outputs and transform the structure of data into 
information contained in the data. The logic or the procedure that a process uses to 


complete its task is not shown. Processes are titled by using verb-clause form. 
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c. Data Store 
Data stores, as the name implies, shows the logical storage of the 
information. Data flow from a data store represents the "usage" of data. This is the place 
where the data are stored after a process, or from where they are retrieved to be 


processed. 


d. Data Flow 
The data flows represent inputs or outputs that move from or to processes 
and from or to data stores. They are titled by a noun-clause form. Data transferred 
together must be shown as a single data flow no matter how many documents are 
physically involved. 

There are two different but equivalent symbol sets for DFDs; the Gane-Sarson 
symbols and the DeMacro-Yourdon set. The use of these sets is based on which one the 
user feels more comfortable with. Figure 4, introduces the two different sets of models 
and shows how the entities, the data flows, the processes and the data stores are 


represented in each of the models. 
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Figure 4: DFD Models 
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e. Leveling of DPDs 

When studying, analyzing and designing a system, it is good to have a 
generic pictorial outline of what the system does or will do when it is implemented. This 
pictorial outline which is called "Decomposition Diagram", also called "hierarchy chart", 
shows the top-down functional decomposition or structure of a system. Decomposition 
diagrams also provide an outline for drawing the DFDs. Only the processes are presented 
on decomposition diagrams and they are connected to form a treelike structure. Process 
names conform with the ones that are referred to in the DFDs. The top process is called 
the root; it is exploded or factored out to subsystems, functions or tasks. It defines the 


scope and boundary of the system to be developed. 


D. DATABASE DESIGN 

The goal of the design phase is to develop a blueprint of all five components, 
shown in figure 2, of the information system. For the data component, the structure of 
the database is developed. To accomplish that, the development team translates the user 
data model into specific data structures. For the process component, the process model 


is transformed into an application design. 


1. Logical Database Design 
After the semantic objects are developed, the next step is to transform these 
objects into a relational design. The resulting relations are then normalized. This is a 


very important part of the design because we need to be sure that the objects’ relations 
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will not suffer from any update anomalies. The process of normalization is discussed in 


the following section. 


a. Normalization 
Normalization is the process of forming well-designed relations by 
grouping attributes together. This process examines the relations to test if they are in one 
of the predefined normal forms. The normalization process ensures data is stored in a 
manner that minimizes data redundancy and update anomalies while maintaining data 


integrity. The normal forms are shown in figure 5. 


First Normal Form {1NF) 


Boyce-Codd 
Normal Form 
Fifth Normal (BCNF) 


Form (SNF) Fourth Normal 
Form {4NF) 


Domain/key 





Figure 5: Normal Forms and their Relationship 
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As indicated in figure 5, each of the higher normal forms contains the lower ones. 
This means, for example, that a relation that is in the third normal form is also in both 
first and second normal forms. Therefore the steps in the normalization process are 
progressive and one normal form follows another. In each step only certain anomalies 
are eliminated. It is mandatory for relational database designers to satisfy the 


requirements of all the normal forms to ensure that all anomalies have been eliminated. 


(1) First Normal Form (INF) 
A relation is in the first normal form if it has no repeating groups. 
That means that all the attributes in the relation are atomic. Since this is the definition 
of the relation, we can safely say that every normalized relation is in the first normal 


form. 


(2) Second Normal Form (2NF) 
A relation 1s in the second normal form if it is in first normal form 
and all non-key attributes are dependent on all the attributes of the key. If the key is a 
single attribute then the relation is automatically in the second normal form. If the key 
is a Set of attributes then all the non-key attributes must be fully functionally dependent 


on that key. 
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(3) Third Normal Form (3NF) 
A relation 1s in the third normal form if it is in second normal form 
and it has no transitive dependencies. A transitive dependency occur if A>B, B->C, then 


A->C. 


(4) Boyce-Codd Normal Form (BCNF) 
A relation is in Boyce-Codd normal form if it is in third normal form 
and every determinant is a candidate key; any attribute that functionally determines any 


other attribute is a candidate key. 


(5) Fourth Normal Form (4NF) 
A relation is in the fourth normal form if it is in Boyce-Codd normal 
form and the multivalued dependencies are eliminated. This case exists when there are 
more than two attributes in a relation, two of them are multivalued, and their values 


depend only on a third attribute. 


(6) Fifth Normal Form (SNF) 
A relation is in the fifth normal form if it is in forth normal form 


and does not have a joint dependency. 


(7) Domain / Key Normal Form (DK/NF) 
A relation is in Domain/Key normal form if every constraint of the 
relation is a logical consequence of the definition of keys and domains. A domain is a 
description of the allowed values of an attribute. Fourth, fifth and the domain/key normal 


forms have little practical usefulness and are usually ignored in practice. 
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2. Application Design 
The design phase includes the design of both the database and the application. 
An application is the collection of menus, forms, reports, and programs that provide a 
means of update, display, and control the objects of the data model. During the 
application design, the specific structure of forms, reports, menus, and query facilities are 
defined. Also, the logic of transaction programs that will be written for the system is 


developed. The application design will be discussed further in chapter IV. 


E. DATABASE IMPLEMENTATION 

The system's implementation is the set of activities following the logical design, and 
consists of the production of a working system that accepts input from the user, processes 
data and produces the desired outputs. One very important task during the development 


of a software application is the development of the user's manual. 


F. OTHER CONSIDERATIONS 

Important issues such as testing, security, training, conversion, maintenance, and 
future upgrades will be considered and discussed later in chapter VI. 

Testing has been defined as "the fiendish and relentless process of executing all or 
part of a system with the intent of causing it to exhibit a defect" (Page-Jones, 1988, p. 
358). The testing phase has traditionally involved first the testing of separate parts of the 
system and then the testing of the system as a whole. The whole system is then tured 
over for acceptance testing (quality assurance). Acceptance testing is carried out by the 


user, the user's representatives, the analysts, the standards group, external system auditors, 
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or any combination thereof. Structured techniques emphasize the interweaving of the 
testing phase as much as possible with the implementation phase so that the system 
quality is "built in" rather than "added in" after the fact. The development of test cases 
and a test plan can begin at the end of analysis and be carried out during the design phase 
itself. This will ensure that testing 1s ready to begin as soon as the implementation phase 


commences. 


1. Testing Techniques 
All testing involves the following six steps: 

a. Select what is to be measured by the test. The goal of the test must be 
determined. Are the requirements to be tested for completeness? Is the code being tested 
for reliability? Is the design being tested for cohesion? 

b. Decide how whatever is being tested is to be tested. A decision of how to test 
for quality must be made. A wide variety of approaches are available, including 
inspection, proofs, black box and white box testing, and automated methods. The tester 
must decide what kind of test is to be used to measure the desired quality. 

c. Develop the test cases. Once the actual test has been decided the actual test 
cases must be created. A test case is simply a set of data or situations that will be used 
to exercise the unit being tested. 

d. Determine the correct or expected results from the test and create the test oracle. 
It is very important for the tester to know what the correct result should look like, and 
determine the "test oracle" which is the predicted results for a set of test cases. 


e. Execute the test cases. In this step the tester has to carry out all the tests. 
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f. Compare the results of the tests to the test oracle. A very careful comparison 
between the actual results of the test and the test oracle should be done in this step. Any 
discrepancy between the predicted results and the actual results signals an error. The 
source of the error must be tracked down. In most cases the error is in the system that 
is being tested. However, in some cases, the error may be in the testing process or in the 
test oracle. 

In order to understand the testing techniques more clearly let's take the sample 
system of figure 6, and see in what ways this system can be tested. Figure 6 shows a 
sample modular hierarchy of a hypothetical system. Modules A,B,C,D,E,F and G 


represent parts of the developed units/code to be tested. 





Figure 6: Sample Modular Hierarchy 


a Traditional Approach to Testing 
Figure 7 shows the traditional testing technique which requires testing 
every module after its completion phase, integrating the whole system, and testing the 


complete system at once. Following the traditional testing technique the tester may 
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experience difficulties at the integration point where he has to test the complete system 


and where most of the problems are surfaced. 
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Figure 7:Traditional Testing 


b. Top-down Testing Strategy 
In this case the testing procedure is driven by the system modular 
hierarchy and follows the top down design. Figure 8 shows the top-down testing strategy 
which is characterized by relatively early integration, no need for module drivers (modules 
that are not fully implemented), low work parallelism at the beginning, and difficulty in 


testing particular paths, and planning and controlling the sequence of tests. 
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Figure 8:Top-down Testing 


c. Bottom-up Testing Strategy 
Figure 9 shows the bottom-up testing strategy in which every individual 
module is tested starting from the bottom and working backwards to the top. This 
technique is characterized by late integration, need for module drivers, medium work 
parallelism at the beginning, ability to test particular paths easily, and difficulty to plan 


and control the sequence of tests. 





Figure 9: Bottom-up Testing 
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d. Sandwich Testing Strategy 
Figure 10 shows the sandwich testing strategy which is a combination of 
both top-down and bottom-up testing strategies, and ensures that all the modules have 
been implemented as soon as the "Test A, B, C, D, E, F, G" modules have been tested. 
This technique is characterized by early integration, medium work parallelism at the 
beginning, medium ability to test particular paths, and difficulty to plan and control the 


sequence of tests. 
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Figure 10: Sandwich testing 
2. Secunty 
Database security is important because databases are so critical to an 
organization. Even with an efficient operating system, data 1s at risk if a reliable database 
system 1S not used. Operating systems usually protect data at the file level. Databases 


however need protection at different levels such as table or relation, row or tuple, or even 


28 





element. In addition, different discretionary security policies are often desired for 
database systems that restrict access to specific data through specific operations, such as 
insert, update, retrieve and delete. Such controls are not available in operating systems. 

There are seven conceptual requirements for database security. These are 
authentication, access control, availability, physical integrity, logical integrity, element 
integrity and audit trail. There is a certain amount of dependence between these seven 
aspects, since a failure in one area may expose the database to increased Patnerability 
from the remaining areas. 

A uthentication 1s the requirement to positively identify every user of the database. 
This may be achieved through the use of information known only to a particular user, 
(e.g. password), the use of some physical item, (e.g. a key or pass card), or reference 
to some physical aspect of the user (e.g. fingerprints, voice pattern). 

Access control defines the who and the what of allowed activities on the system's 
data. The who describes which subjects have access to which objects. The what defines 
the operations (e.g. read, write, etc.), allowed on each object. Figure 11 shows an 
example of an access control list for three users and three relations. This sample access 
control list permits user "X" to access relation "A" to insert, read, update and delete data. 

A vailability means that authorized users should not experience denial of service. 

Physical security involves protecting the media which stores the database from 
damage. This may include measures to protect the physical media from natural disasters, 


fire, and accidental or intentional abuse. 
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I: insert. r: read, u : update, d : delete. 





Figure 11: Access Control List Example 


Logical integrity involves protecting information about the logical structure (schema) 
of the database, which in many occasions is stored separately from the base data. 
Element integrity is concerned with the accuracy and correctness of the data in each data 
element. 

Audit trails answer the who, what and when about access to data in the database. 
It is a permanent record of who has accessed what elements of the database, what actions 


were performed upon them, and when the action took place. 


3. Conversion 
The conversion phase is probably the most important phase of the system 
implementation from a managerial perspective. This is the time that users and system 
development personnel have to work closely together. Human nature 1s to resist any kind 
of changes, especially if they are not ready or prepared for that change. Factors such as 
organizational structure, human resources, and political and cultural climate all come into 


play. Management sometimes has to restructure the organization chart when a 
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computerized system is implemented into the organization environment. Human resources 
are often reallocated to and from the new system so the principle of "the nght man in the 
night position" will be guaranteed. Conflicts among users and workers who don't believe 
in automation should be expected. Furthermore, some employees view training programs 
as a threat because they believe that evaluations made at the end of the training will be 


used against them. 


a Strategies 
There are four strategies that can be used to implement a system. 
They are: Parallel Conversion, Direct Conversion, Phased Conversion, and Pilot 


Conversion. 


(1) Parallel Conversion 
Figure 12 shows the parallel conversion technique which is widely used. It 
consists of operating both the old and the new system at the same time, until management 
is satisfied that the new system is working efficiently. At this point the old system is 
discontinued. This technique eliminates the risk involved with implementing a new 


system, but requires a lot of manpower to maintain both systems in operation. 


31 


Sourse 
Documents 


J inputs / 





Figure 12: Parallel Conversion 


(2) Direct Conversion 

Figure 13 shows the direct conversion which is characterized by 
shutting down the old system at the end of one workday and starting up the new system 
the next workday. This technique can be extremely risky, but it 1s gaining in popularity 

over the parallel conversion strategy for the following reasons: 
¢ By using the parallel approach, the need for manpower is _ greater. 
Furthermore, by continuing with the old system, it may cause some users not 

to make a genuine effort to support the new system 
° With thorough testing of the system and training of the personnel, the new 

system should operate at acceptable levels 


. In many cases the risk of failure of the new system may be acceptable 
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Figure 13: Direct Conversion 


(3) Phased Conversion 

Figure 14 shows the phased conversion technique through which the 
old system is phased out and the new system 1s gradually phased in. This approach has 
many of the same problems that parallel conversion has, primarily because both systems 
operate simultaneously. Furthermore, the outputs of the two systems have to be combined 
to obtain a total picture. Finally, by shifting to the new system, no backup of the old one 
exists, and if ae system fails then the only way to retrieve lost information is by 
reverting completely to the old system. The big advantage is that the shift from the old 
system to the new one 1s quite smooth. As the user gradually becomes familiar with the 
new system while continuously using it, he starts seeing the advantages of the new 


system. This is a key factor in minimizing user resistance. 
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Figure 14: Phased Conversion 


(4) Pilot Conversion 
Figure 15 shows the pilot conversion technique. Pilot conversion 
consists of implementing the new system in a Selected portion of its ultimate site. If the 
system operates efficiently on this selected portion, it 1s then fully implemented at the 
entire site. Within the pilot area, the system can be implemented in any of the previously 
discussed methods. The pilot approach avoids many of the problems that the other 
alternatives have. One drawback however, ts that it does not test whether the system will 


operate satisfactonly under the increased volume of full implementation. 
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Figure 15: Pilot Conversion 
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I. REQUIREMENTS ANALYSIS FOR SPAS 
In this chapter we will discuss both the data and the process requirements for the 
SPAS application. We will create the data model and the corresponding data flow 
diagrams that represent the data flow that create, update and display the objects of the 


data model. 


A. DATA REQUIREMENTS 

Data requirements are captured in the form of semantic objects and associated data 
dictionary. This application consists of seventeen (17) semantic objects that are shown 
in Appendix A. In this diagram objects and object properties are indicated in upper case, 


attributes in mixed case, and identifiers are underlined. 


1. SHIP 
A ship has a name, belongs to a class, is commanded by a Commanding 
Officer, helped by an Executive Officer and belongs to a higher command. The ship 


internally 1s organized into DEPA RTMENT=s. 


2. DEPARTMENT 
A department has a name, is controlled by the department head who is an 
officer, and has an office and a phone number. It belongs to the SH/P and contains and 


controls one or more DIVISIONS. 
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3. DIVISION 
Similar to a department, a division has a name, is controlled by the division 
officer, and has an office and phone number. Every division has one or more PERSONS 


and belongs to a DEPARTMENT. 


4. PORT DUTY STATION 
A port duty station that the PERSON could be assigned to while in port has 


a name, a location and a phone number. 


5. PERSON 

The persons onboard the ship work for a DIVISION. Every person has a 
unique identification number, a first and last name, a military rank and rate, owns a 
current position after being reassigned from his previous one on a certain date, has a 
specialty, and should belong to three different division systems in order to be able to 
complete his individual tasks depending on the general ship's situation. These systems 
are the one third crew division system that applies when the ship is underway with three 
watch shifts, the one half that applies when the ship is on two shifts and a session 
division system that applies every moming while in port for the XO's daily report. Every 
person has a date of birth, an address, has to provide his nearest police station address and 
phone number in case of emergency, has a religion, hobbies, background education and 
may speak one or more foreign languages. As soon as he embarks he ts assigned a 
berthing place, some SPECIAL DUTIES, a PORT DUTY STATION, an ABANDON 


SHIP STATION in case of an abandon drill or a real situation and one or more SPECIA L 
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STATION when the ship is mooring, anchoring towing or being towed. At any time, a 
person has the right to take LEA VE or to ask for a SPECIAL REQUEST. The command 
is also interested in other personal data, like the person's DEPENDENT=s, his FITNESS 
condition, his PROMOTIONS and some work experience data, such as being qualified as 
an air controller and his current qualification category. Any time he performs AJR 
CONTROL CHECKs it is recorded and the ship is required to report it every month. 
Furthermore, all personnel are subject to periodic ON THE JOB TRAINING 
EVALUATIONS. Finally, a person undertakes TRAJNING and is_ subject to 


DISCIPLINARY actions. 


6. SPECIAL STATION 
A special station that the PERSON could be assigned to has a type anda tile. 
The person has a duty and has to carry some equipment and there is a /ocation where all 
the persons have to be gathered. 
7. SPECIAL DUTY 
Similar to the station, a special duty that the PERSON could be assigned to 
has a type, a title and each person has some instructions. They have to carry some 
equipment and/or some armament depending on the mission and there 1s a /ocation where 


they have to be gathered. 


8. DEPENDENT 
The crewmember's ( PERSON )dependent has a name, lives at an address, and 


has a phone number. There is a possibility that the crewmember has other dependents. 
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9. DISCIPLINARY 
Any PERSON onboard could commit an " illegal " action and be disciplined. 
That offense reported by an officer, has a number, a name and a date when it was 
committed. The person has the right to give his apology, while the command has to 


decide his punishment, the date that punishment starts, and the date that it ends. 


10. PROMOTION 
Normally, after a certain period of time the PERSONs onboard, commissioned 
officers and petty officers get promoted. The command needs to know the promotion 


date, the command issued the order for the promotion and the date of the issued order. 


11. FITNESS EVALUATION 
Once a year, all PERSONS have to be evaluated for their fitness condition. 
The fitness evaluation has a reference period, a start date, an end date, a pass or fail 


evaluation grade and any possible comments. 


12. ON THE JOB TRAINING (OJT) EVALUATION 
PERSONS periodically are evaluated on their job in order to be qualified or 
to refresh their technical skills and knowledge. The OJT evaluation is performed by the 
person's department head, has a start date, an end date, the resulting grade, any possible 


comments and the station that the person is qualified for. 


13. TRAINING 
The training of crewmembers is a continual activity. There are required 


schools that crewmembers have to attend in order to get promoted and there are schools 
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whose attendance is on a volunteer basis. The ship's command needs to know what 
school each of the PERSONs have attended, the date, the degree or the diploma, the grade 
that the person obtained, his order of success among the other participants and any 


possible comments. 


14. AIR CONTROL CHECK 
PERSONS that are qualified as air controllers and are capable of performing 
tactical control on fixed wings or helicopters have to record each control check they 
perform, and the ship's command has to submit a consolidated report every month to the 
Tactical Training Center. The air control check has a date and a time that the control was 
performed, the type of the aircraft, the type of the control and its duration and possible 


comments. 


15. LEAVE 
By law, each person ts entitled to 30 days normal leave every year. However, 
depending on the situation and the CO's decision, he could get additional days off. This 
special leave could be for personal/private reasons or for educational purposes. For 
example, special leave could be granted while the person is studying at a university and 
has to take exams, or, it could be given as a reward. The PERSON'S leave is described 
by its type, has a date starts, a date ends, the number of days in leave, destination, as well 


as any possible comments. 
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A crewmember serving onboard the ship can submit requests, mostly 
conceming administrative issues. He can ask to report something personal to the CO or 
the XO, or ask to be heard by the higher commander or even by the Admiral of the Fleet. 
PERSON's request has to be recorded and has a date, a type, a description, the CO's 


decision and any possible comments. 


17. ABANDON SHIP STATION 
On the " ABANDON SHIP " order, everyone has to be at his abandon ship 
station. This is any of the life rescue facilities of the ship either a rescue boat or a 
floating raft. The abandon ship station has a number, a location, a type and a capacity. 


All of the PERSONS are assigned to an abandon ship station. 


B. DATA DICTIONARY 
The SPAS application data dictionary is shown in Appendix B. It describes each 


object, its properties, the data type, width, and definition of each property. 


C. PROCESS REQUIREMENTS 

In this application, the decomposition diagram and the data flow diagrams that 
describe the system's functionality are shown in Appendix C. The system has four levels. 
The zero level is the overall system picture named Shipboard Personnel Administration 
System ( SPAS ). It is factored into three different subsystems titled Personnel 


Subsystem, Request Subsystem and Report and Query Subsystem. 
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a Personnel Subsystem 

This subsystem has five processes: process crewmember data, process 
dependent data, process disciplinary data, process evaluation data and maintain person 
data. The process evaluation data consists of two subprocesses: on the job training 
evaluation data and fitness evaluation data. The maintain person data process consists of 
five subprocesses to update the air control, crewmember, dependent, disciplinary and 
evaluation data. All these subprocesses have add, modify and delete mechanisms. Of 
special interest is the process crewmember data process through which all of a person's 
data is entered into the system as well as his assignment to special duties and special 


Stations. 


b. Request Subsystem 
The request subsystem has only two processes to process any kind of 


special request or leave request. 


c. Report and Query Subsystem 
This subsystem produces predefined reports either for internal or external 
use. The answer specified queries process is considered a utility for the production of 
internal reports to support the ship's command with any kind of information relative to 
a person. The produce intemal reports process 1s split into the following subprocesses: 
produce person's information card, produce person's information book, produce fitness 
evaluation report, produce a division system repon and produce a special duty report. 


The produce extemal reports process produces the air controllers’ monthly report, the 
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officers' special report, the officers' monthly report, the sailors' monthly report and the 


sailors punishment monthly report. 


D. HARDWARE REQUIREMENTS 

The system being developed will be implemented on an IBM compatible PC 
platform found on many Hellenic Navy ships. The minimum hardware configuration is 
a 386 SX (16 bit architecture) processor running at 25 Mhz, with 2 Mb of RAM and 65 
Mb of hard drive. 

The following chapter will describe the logical database and application design for 


SPAS. 
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IV. LOGICAL DATABASE AND APPLICATION DESIGN FOR SPAS 

In this chapter we will discuss the logical database and application design for SPAS. 
In logical database design, the object model developed in the previous chapter is 
transformed into a relational schema, in preparation for implementation using a specific 
DBMS. In application design, the data flow diagrams are used as a basis for developing 


the menus, forms, and reports for SPAS. 


A. LOGICAL DATABASE DESIGN 

The seventeen semantic objects describing the user's environment are transformed 
into nineteen relations. Relationships are represented using foreign keys and are also 
shown explicitly on the relational diagram. In this diagram, shown in Appendix D, 
primary keys are underlined and foreign keys are indicated with the superscript **. 
Relations of Appendix D, their attributes, and relationships are discussed in the following 
sections. 

1. Ship Relation 

This relation contains information about a ship. It is derived from SHIP 

object. Its primary key is Hull Number. Other attributes are Ship's Name, Ship's Class, 
Commanding Officer's Name, Executive Officer's Name, and Higher Command. It has 


a 1:M mandatory relationship to Department relation. 
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2. Department Relation 
This relation contains information about a department. It is derived from 
DEPARTMENT object. Its primary key is Department Name. Other attributes are 
Department Head, Office Location, Phone Number and Hull # (foreign key). It has a M:1 


and a 1:M mandatory relationships to Ship and Division relations respectively. 


3. Division Relation 
This relation contains information about a division. It 1s derived from 
DIVISION object. Its primary key is Division Name. Other attributes are Division 
Officer Name, Office Location, Phone Number and Department Name (foreign key). It 
has a M:1 and a 1:M mandatory relationships to Division and Person relations 


respectively. 


4. Person Relation 

This relation contains information about a person. It is derived from PERSON 
object. Its primary key is Personal Identification Number. Other attributes are Last 
Name, First Name, Rank, Rate, Current Position, Previous Position, Date of Change, 
Specialty, Date of Birth, Address, Nearest Police Station and Phone Number, One Third 
Crew Division System Number, One Half Crew Division System Number, Session 
Number, Berthing, Religion, Education, Foreign Languages, Hobbies, Air Control 
Category, Instructor Air Controller, Division Name (foreign key), Port Duty Station Name 
(foreign key), and Abandon Ship Station Number (foreign key). It has a M:! mandatory 


relationship to Port Duty Station, Division, and Abandon Ship Station relations, a 1:1 
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optional relationship to Fitness Evaluation, Dependent and Air Control Check, a 1:M 
mandatory relationship to Promotion, Person-Special Duty, and Person-Special Station 
relations, a 1:M optional relationship to Disciplinary, Training, Request, Leave, and On 


the Job Training Evaluation relations. 


5. Dependent Relation 
This relation contains information about a person's dependent. It is derived 
from DEPENDENT object. Its primary key is Dependent's Name and Personal 
Identification Number. Other attributes are Address, Phone Number and Other Dependent 


Names. It has a 1:1 mandatory relationship to Person relation. 


6. Fitness Evaluation Relation 
This relation contains information about a person's fitness evaluation. It is 
derived from FITNESS EVALUATION object. Its primary key is Reference Period for 
Fitness Evaluation and Personal Identification Number. Other attributes are Start Date, 
End Date, Grade, and Comment. It has a 1:1 mandatory relationship to Person relation. 
7. On the Job Training Evaluation Relation 
This relation contains information about a person's OJT evaluation. It is 
derived from OJT EVALUATION object. Its primary key is Start Date for the OJT 
Evaluation and Personal Identification Number. Other attributes are End Date, Grade, 
Comments, Station duty of Qualification, and Officer Performed the Qualification. It has 


a M:1 mandatory relationship to Person relation. 
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8. Disciplinary Relation 
This relation contains information about a person's Disciplinary actions. It is 
derived from DISCIPLINARY object. Its primary key 1s Offence Number and Personal 
Identification Number. Other attributes are Offence Name, Offence Date, Apology, 
Punishment, Start Date, End Date, and Reporting Officer. It has a M:1 mandatory 


relationship to Person relation. 


9. Training Relation 
This relation contains information about a person's Training. It is derived from 
TRAINING object. Its primary key is School Name and Personal Identification Number. 
Other attributes are Date, Degree/Diploma, Number of Participants, Grade, Order among 


Participants, and Comments. It has a M:1] mandatory relationship to Person relation. 


10. Promotion Relation 
This relation contains information about a person's Promotion. It is derived 
from PROMOTION object. Its primary key is Promotion Date and Personal Identification 
Number. Other attributes are Command Issued the Order, and Date of Issued Order. It 


has a M:] mandatory relationship to Person relation. 


11. Port Duty Station Relation 
This relation contains information about a port duty station. It is derived from 
PORT DUTY STATION object. Its primary key is Port Duty Station Name. Other 
attributes are Station Location and Phone Number. It has a 1:M mandatory relationship 


to Person relation. 
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12. Air Control Check Relation 
This relation contains information about air control checks. It is derived from 
AIR CONTROL CHECK object. Its primary key is Date, Time, and Type of Aircraft. 
Other attributes are Type of Control, Duration, Comments and Personal Identification 


Number (foreign key). It has a 1:M mandatory relationship to Person relation. 


13. Request Relation 
This relation contains information about.a person's requests. It is derived from 
REQUEST object. Its primary key is Date, Personal Identification Number, and Type of 
Request. Other attributes are Description, CO's Decision, and Comments. It has a M:1 


mandatory relationship to Person relation. 


14. Leave Relation 
This relation contains information about a person's leave. It is derived from 
LEAVE object. Its primary key is Date Starts and Personal Identification Number. Other 
attributes are Date Ends, Type of Leave, Number of Days on leave, Destination, and 
Comments. It has a M:1 mandatory relationship to Person relation. 
15. Abandon Ship Station Relation 
This relation contains information about an abandon ship station. It is derived 
from ABANDON SHIP STATION object. Its primary key is Abandon Ship Station 
Number. Other attributes are Location, Type of Rescue Vessel, and Capacity. It has a 


1:M mandatory relationship to Person relation. 
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16. Special Staton Relation 
This relation contains information about a special ship station. It is derived 
from SPECIAL STATION object. Its primary key is Special Station Type and Special 
Station Title. Other attributes are Duty, Equipments, and Gathering Position/Location. 


It has a 1:M mandatory relationship to Person-Special Station relation. 


17. Person-Special Station Relation 
This relation contains information about a person and his special ship station. 
It is derived from PERSON and SPECIAL STATION objects. It is an intersection 
relation that breaks the many to many relationships between person and special station 
into two 1:M relationships. Its primary key is Personal Identification Number, Special 
Station Type, and Special Station Title. It has a M:] mandatory relationship to Person 


and Special Station relations. 


18. Special Duty Relation 
This relation contains information about a special ship duty. It is derived from 
SPECIAL DUTY object. Its primary key is Special Duty Type and Special Duty Title. 
Other attributes are Duty Instruction, Equipments/Guns and Ammunition, and Gathering 


Position. It has a 1:M mandatory relationship to Person-Special Duty relation. 


19. Person-Special Duty Relation 
This relation contains information about a person and his special duty. It is 
derived from PERSON and SPECIAL DUTY objects. It is an intersection relation that 


breaks the many to many relationships between person and special duty into two 1:M 
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relationships. Its primary key is Personal Identification Number, Special Duty Type, and 
Special Duty Title. It has a M:1 mandatory relationship to Person and Special Duty 


relations. 


B. APPLICATION DESIGN 
In application design, the data flow diagrams developed in the requirements phase 
are used as the basis for designing the system's menus, forms, and reports. The following 


section provides a brief explanation of each. 


1. Menus 
SPAS is a menu-driven application. The reason for using menus is because 
they are self explanatory and are therefore easy to use. The menu structure of SPAS 
follows closely the decomposition diagram developed during process requirements. SPAS 


menus are shown in Appendix E. 


2. Forms 
Forms are the user's primary interface with the database. They are used for 
entering, modifying, and displaying data retrieved from the database. Special care was 
paid in designing the forms for SPAS. Every effort was made in designing them to be 
natural, easy to use, and be less prone to errors. SPAS forms are shown in Appendix F. 
3. Reports 
Reports are the main output that the system generates for distribution to a 
variety of users. Reports can be sent to the screen, to a file, or to the printer. Similar 


to designing forms special care was paid in designing the reports for SPAS. Every effort 
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was made in designing them to be natural, logical, close to the format that is currently in 


use, and less prone to misinterpretation. SPAS reports are shown in Appendix G. 


5] 


V. IMPLEMENTATION FOR SPAS 

In this chapter we will discuss the implementation of the SPAS application and the 
construction of the database, as well as the installation of both the database and the SPAS 
application. The Paradox database management system for DOS 1s introduced and used 
as the DBMS of choise for SPAS implementation. 

Paradox is a fast, full-featured, and easy to use relational database program designed 
to meet data management needs. Paradox can be used by computer users with all levels 
of experience from beginning database users to advanced developers. Paradox can be 
used either on a single computer (standalone) or on a Local Area Network (LAN). 

To use Paradox 4.0 on a standalone computer, you will need at a minimum: 

° a 100% IBM compatible, protected mode capable 80286 or higher personal 

computer with a hard disk and a floppy drive 

° 2MB extended memory 

° DOS 3.0 or higher, or OS/2 2.0 

. compatible MDA, MCA, CGA, EGA, VGA, 8514, 3270, ATT, TANDY 

T1000, or Hercules monitor with adapter 

° SMB of free hard disk space to install Paradox without the optional software 

and 0.5MB for the optional software 

. free hard disk space approximately three times the size of your largest table, 


to process complex queries 


Ss 





The user interface for Paradox supports multiple windows, pull-down menus, speed 
bars, dialog boxes, and other graphical user interface components. Paradox provides 
limited mouse support. For instance, you can't change directories when loading tables by 
pointing and clicking at a directory tree with the mouse; you have to type your path 
manually. Paradox's Query By Example (QBE) capability is one of the product's strong 
features. Complex queries can be run against single or joined tables, and query images 
can be saved for later use. A variety of exact and inexact queries can be performed, ~ 
there is support for wildcards, data ranges, pattern searches, and logical conditions. 
Phonetic searches can be done with Paradox's "Like" operator. Database administration 
is handled through Paradox's well-designed user interface which puts all the commands 


the user needs on easy-to-use menus and provides shortcut keys for many of the choices. 


A. DATA IMPLEMENTATION 

In data implementation, the relations and their attributes developed during logical 
database design are transformed into tables and data fields, respectively. Table structures 
are created in Paradox by choosing Create from the menu, and specifying a name for the 
new table in the dialog box. The structure of the new empty table, which matches the 
corresponding relation developed during the design phase, is then specified. For each 
field of the table, its name, field type, and whether it is a key field are entered. Brief 
descriptions of the field type choices are displayed on the new table creation window to 
assist the users in creating the new table. The data types supported by Paradox and their 


abbreviations are: A for alphanumeric fields up to 255 characters in length, M for a memo 
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up to 240 characters in table view, N for numbers, $ for currency amounts, and D for 
dates. Once the definition of a table 1s completed, a user can enter values in the table 


directly or through a form. 


B. APPLICATION IMPLEMENTATION 

A Paradox application is a series of instructions to Paradox that makes it perform 
the set of tasks needed to do a specific job. These instructions link menus, forms, 
queries, and reports into a comprehensive system. In this section we will discuss Paradox 
query module, form and report generator, and application workshop. 

Query module lets the user select, combine, manipulate, and retrieve data in tables. 
To perform a query, a query form has to be filled out first. This form is related to the 
table that contains the data) The Ask command on the main menu displays the Query 
form. Several forms can be linked together, and the designer 1s able to retrieve all the 
information he needs into a single table. He can also set conditions to be satisfied when 
the query is performed. Setting conditions is a simple action of making the Query form 
look like an example of the records he likes to retrieve. This is called Query by Example. 
The retrieved data are stored in a temporary table named Answer. 

Paradox has a form/report generator that allows the programmer to design custom 
forms and reports. Forms are used to input data one record at a time. A form can have 
wrapped fields that show the information of a single field on two or more lines. The 
information in a table image is always arranged in rows and columns, whereas the 


information on a form can be arranged in a free format. Data fields are highlighted in 
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different colors for easy recognition with a cursor that tabs from one logical data field to 
the next. Forms are created by choosing Form, Design from the menu. Paradox default 
is a standard tabular formatted form. The designer has the option to design a custom free 
format form. Appendix F shows SPAS data input forms. 

Reports are produced to display the requested information from the database. Each 
table can have up to 15 reports defined on it. Each report can have up to 2000 characters 
per line. Reports are created by choosing Report, Design from the menu. Paradox default 
is a standard column report. The designer has the option to design a custom free format 
report. Appendix G shows SPAS customized reports. 

Paradox application workshop helps the programmer to create Paradox Applications 
easily. The application menus are created through the application workshop. Building 
the menus and defining what each command menu does is accomplished through the 
application workshop. The application workshop creates and manages the components 
of the application. Another way to create these components is by using PAL 
(Programming Application Language) scripts which is more complex and designed for 
more advanced applications and experienced programmers. For the development of SPAS 
application, a combination of both the application workshop and PAL was used. 

Appendix H shows the programming code generated by Paradox while building the 
SPAS application. Part one of the Appendix is the "Menu Structure" that shows the 
hierarchy of the SPAS application menu structure. Part two is the cross-reference table 
of "Action Objects & Paradox Objects in Use" that explains in each session what tables 


are declared, what functions (insert, edit, delete) are performed, and if the specific session 
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is password protected. Part three is the action table menu that describes in detail how 
each of the actions is performed. 

Appendix I provides procedures for installing and operating SPAS. 

The next chapter discusses other issues that need to be taken into consideration 


before SPAS can be fully operational. 
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VI. OTHER ISSUES 
In this chapter important issues concerning the development of the "SPAS" 
application such as testing, security, training, conversion, maintenance, and future 


upgrades will be discussed. 


A. TESTING 
As mentioned in chapter II, testing is critical for the development of the SPAS 
application. Database management system testing abilities as well SPAS testing strategy 


will be discussed at this point. 


1. Paradox Testing 
Paradox is designed to allow the developer to conduct testing through the use 
of environments. In the "Workshop" environment, after each programming session is 
implemented the user is able to test the specific module and be assured that it is fully 
functional without any procedural errors. When the application is finished, it can and 
must be tested as a whole. Paradox has that feature built in the application workshop 
under "Application/Test" which tests the application to ensure that everything after the 


integration works properly. 


2. ‘“SPAS" Testing Strategy 
As mentioned in the previous paragraph, Paradox lets the developer test the 
application at every procedural step. While building each of the action menus, the 


developer is able to test every action, session, or report, to ensure that everything 1s 


am 


working properly, and continue to the next menu for further development. So, in this 
session, access to all of the tables and forms is ensured, all queries are performed, and 
everything 1s verified to be working properly. This "built in" testing procedure in Paradox 
represents the bottom-up testing strategy that 1s described in paragraph II.E.2.c. The 
bottom-up testing technique was performed throughout the development of the SPAS 
application and each individual process was tested before proceeding to the next higher 
step in the application's hierarchy. Each subsystem was tested in that way ensuring no 
functional or procedural errors were present. The whole application was then tested as 


a complete and integrated system. 


B. SPAS SECURITY 

Paradox offers a very flexible passwording scheme with table-by-table, 
script-by-script, and option-by-option password protection. Access to a given table can 
be limited on a field-by-field basis. 

SPAS users will have some access control authorities depending on their rank and 
their duties onboard the ship. The command 1s responsible for assigning these duties and 
for determining each user access control. 

SPAS physical security falls under the navy's policy and procedures that enforce 
rules and activities for the ships' physical security. Moreover, each individual ship 
command has to take proper measures to protect the hardware resources as well as the 


software and the applications. 
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C. TRAINING 

One of the most important aspects of the implementation phase is the training plan. 
The training plan is designed to ensure that every user of the system knows the system's 
basic functions and how to perform them. The success of any information system 
depends on the skills of the operators. In the SPAS system, the operators are officers, 
petty officers and sailors, who are familiar with the procedures on the ship, currently run 
the system manually, and who only need to be taught how the new system operates. The 
system itself is designed to be friendly, easy-to-use, and does not require the operator to 
have any advanced interpersonal skills. However, matching basic human characteristics 
and skills with a job's requirements 1s essential, especially when an automated system is 
to replace a manual one. 

The designer's proposal for the training is to start with the main users of the system 
and train them in the system's environment as well as its functions and operations. The 
main users of the system are defined as personnel working in the ship's administration 
office. They are led by the administration officer whose team normally consists of two 
petty officers and three or four sailors. As soon as every ship has a trained core of 


system users, training for the rest of the personnel can be held. 


D. CONVERSION 
The future success of the new system depends on how well and how quickly it is 
accepted by the users. With SPAS application, it is hoped that because the system is 


rather small and the users are already familiar with the environment, proper training will 


Bh, 


minimize these problems. Another way to minimize implementation problems 1s to select 


the correct conversion strategy. 


1. SPAS Conversion Strategy 
For the SPAS application conversion strategy, the pilot approach is proposed. 
A parallel conversion within two Hellenic Navy ships as pilot units is desired for the 
following reasons: 
° risk 1s significantly minimized 
° testing the system on two ships over a period of time will provide sufficient 
information to evaluate the system before complete implementation on all 
ships 
* manpower need is reasonable 
° surfaced problems can be worked out by the personnel of both ships 
° time to shift is predicted to be two months which is a reasonable interval for 
checking monthly reports and for reassigning personnel from/to the ship 
As soon as the system operates sufficiently on the pilot units, a decision for full 


implementation on all ships can be made. 


E. MAINTENANCE 

Once the system passes the acceptance test, it 1s ready for delivery. Any 
modifications or enhancements after delivery is called maintenance. Attention should be 
paid to the fact that after a few years of operating the original system, maintenance 


becomes extremely tedious, error-prone, and expensive. In this case, management should 
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recognize the problem and do a feasibility study on replacing the old system with a new 


one. 


F. FUTURE ENHANCEMENTS 

The SPAS system design offers a flexible way for future upgrades. Paradox itself 
can be distributed on a network and allow applications to be shared among different users. 
The SPAS system is able to produce all the designed reports in file format. This facility 
allows ships to electronically transfer their reports as soon as all the commands are 


connected to a common network. 
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VIL CONCLUSIONS AND LESSONS LEARNED 

This thesis presented the design, development, partial testing and implementation 
of the Shipboard Personnel Administration System (SPAS) application on a standalone 
computer. The SPAS system will provide the Hellenic Navy ships with an automated 
system to perform their primary administrative functions. SPAS supports this mission by 
keeping track of all the personnel records, maintaining them, producing reports and 
providing the command with ad hoc information. 

No automated system is currently in use and all the administrative activities are 
performed by a manual filing system which is slow, inaccurate and prone to errors. The 
main goal of developing the system is . release manpower to perform other duties, by 
increasing effectiveness, efficiency, and accuracy of personnel management. After SPAS 
implementation, it is hoped that most of the current problems wil! be eliminated, and 
future enhancements will result in even greater efficiency in performing the personnel 
administration functions. 

System analysis and design tools and techniques were used to develop the system 
by modeling the user data and process requirements. Paradox for DOS was used as the 
database management system for the implementation because it is not only powerful but 
also meets the system's developmental requirements. The window like, pull-down menu 


driven environment Is easy to uSe and quick to leam. The user friendly environment will 
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hopefully eliminate the cultural resistance of the user that will result from the requirement 
to switch from the manual system to an automated one. 

It is hoped this thesis will be the motivator for other efforts to develop new systems, 
and expand or update existing ones in the Hellenic Navy. It is hoped also that the 
developed system would benefit other services of the Hellenic military and give them the 
inspiration to develop their own systems following the pre-designed and tested system 


designed for the Navy and developed in this thesis. 
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APPENDIX A: SEMANTIC OBJECTS 


Hull # 


Ship's Name 
Ship's Class 
CO's Name 
XO's Name 


Higher Command 


DEPARTMENT 
mv 


SHIP 





Division Name 
Division Officer Name 
Office Location 
Phone # 


PERSON 


DEPARTMENT 





DIVISION 


Title 
Duty 
Equipments 


Gathering Position/Location 


PERSON a 


SPECIAL STATION 
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Department Name 
Department Head 
Office Location 
Phone # 


DIVISION 





DEPARTMENT 


Port Duty Station's Name 
Location 
Phone # 


PERSON mv 


PORT DUTY STATION 





Type of Duty 
Duty Title 


Duty Instructions 


Equipment/Gun+Amo 
Gathering Position 


PERSON | my 


SPECIAL DUTY 





a EE 


Personal ID # 
Last Name 
First Name 
Rank 


Rate 
Current Position 
Previous Position 
Date of Change 
Specialty 
1/3 Crew Division # 
1/2 Crew Division # 
Session 
Date of Birth 
Address 
Nearest Police Station & Phone # 
Berthing 
Air Control Category 
Instructor Air Controler (Y/N) 
Religion 
Education 
Foreign Languages mv 
Hobbies mv 


TRAINING — 


OJT EVALUATION 


DEPENDENT 


PROMOTION mv 


FITNESS EVALUATION 


DIVISION 


DISCIPLINARY | py 


ABANDON SHIP STATION 


SPECIAL STATION 


mv 


SPECIAL DUTIES 
mv 


2 


REQUEST 


LEAVE 
mv 


AIR CONTROL CHECK 
mv 


PORT DUTY STATION 


PERSON 


6 


a) 


Offence # 





Address Offence Name 
Phone # ange Offence 
Other Depentent's Name SE Sve 
Start Date 
DEPENDENT End Date 


Reporting Officer 





DISCIPLINARY 


PERSON 


Command Issued the Order 
Date of Issued Order 





PROMOTION 


Reference Period Start Date 


PERSON 
start Date 


End Date 
Grade 
Comments 


End Date 

Grade 

Comments 

Station Duty of Qualification 
Officer Performed the Qual. 





FITNESS EVALUATION OJT EVALUATION 
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Date 
Time 


Type of Aircraft 
Type of Control 
Date Duration of Control 


Degree/Diploma 
No. of Participants Comments 


Grade 
Order of Success among Participants PERSON 


Comments 





TRAINING AIR CONTROL CHECK 


Date Starts Date 
Date Ends 


Type of Leave Type of Request 


No. of Days Description 
Destination CO's Decision 


Comments Comments 





LEAVE REQUEST 


Shondin Shin SHiene: 
Location 
Type of Rescue Vessel 


Capacity 
mv 


ABANDON SHIP STATION 
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ELEMEN J 
SHIP OBJECT 
Hull # 

Ship's Name 
Ship's Class 

CO's Name 

XO's Name 
Higher Command 


DEPATRMENT 


DEPARTMENT OBJECT 


Department Name 
Department Head 


Department Office Location 
Department Phone # 

SHIP 

DIVISION 


DIVISION OBJECT 


Division Name 
Division Officer Name 


Division Office Location 


Division Phone # 
PERSON 


DEPARTMENT 


APPENDIX B: DATA DICTIONARY 


TYPE WIDTH DESCRIPTION 


:Alphanumeric 
:Alphanumeric 
:Alphanumeric 
:Alphanumeric 
:Alphanumeric 
-Alphanumeric 


:DEPARTMENT 


object; MV 


:Alphanumeric 
:Alphanumeric 


:Alphanumeric 
:Alphanumeric 


‘SHIP object 
:DIVISION 


object; MV 


:Alphanumeric 
-Alphanumeric 


-Alphanumeric 


:Alphanumeric 
-PERSON 


object; MV 


:DEPARTMENT 


object 
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i) 
> 


10 


15 
oes 


Ship's Hull #. 

Ship's Name. 

Ship's Class. 

CO's Name. 

XO's Name. 

Higher Command that the 
ship belongs to. 


Name of the Department. 
Name of the Department 
Officer. 

Location of the 
Department Office. 
Department Office Phone #. 


Name of the Division. 
Name of the 

Division Officer. 
Location of the 

Division Office. 
Division Office Phone #. 


PORT DUTY STATION OBJECT 
Port Duty Station Name 

Location 

Phone # 

PERSON 

PERSON OBJECT 

Personal ID # 

Last Name 


First Name 
Rank 


Rate 
Current Position 


Previous Position 


Date of Change 


Specialty 
1/3 Crew Division Number 


1/2 Crew Division Number 
Session Number 

Date of Birth 

Address 

Nearest Police Station 


& Phone # 


Berthing 


:Alphanumeric 
:Alphanumeric 


:Alphanumeric 
:=PERSON 


object; MV 


:Alphanumeric 
:Alphanumeric 


:Alphanumeric 
: Alphanumeric 


:Alphanumeric 
-Alphanumeric 


:Alphanumeric 


‘Date 


‘Alphanumeric 
:Alphanumeric 


:Alphanumeric 
:Alphanumeric 
:Date 

:Alphanumeric 
:Alphanumeric 


:Alphanumeric 
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1s 


10 


ES 
15 


30 


50 


10 


Name of the 

Port Duty Station. 
Location of the 

Port Duty Station. 

Port Duty Station Phone # 


Person's 

Identification Number. 
Person's Last Name. 
Person's First Name. 
Person's Rank: 

O: if Officer, 

P: if Pety Of., 

S: if Sailor. 

Person's Rate. 
Crewmember Current 
Position of his Job. 
Crewmember Previous 
Position of his Job. 
mm/dd/yy 

Date of Change from 
Previous Position to 
Current Position. 
Person's Specialty. 
Number of "1/3 

Crew Division System". 
Number of "1/2 

Crew Division System". 
Number of XO's 

Daily Session. 

Person's DoB, 
mm/dd/yy. 

Person's Home Address. 


Police Station 
closest to Person's Home. 
Person's Berthing Place. 


Air Control Category 


Instructor Air Controller 
Religion 

Education 

Foreign Languages 


Hobbies 
TRAINING 


OJT EVALUATION 
DEPENDENT 
PROMOTION 

FITNESS EVALUATION 
DIVISION 
DISCIPLINARY 
ABNDON SHIP STATION 
SPECIAL STATION 
SPECIAL DUTY 
REQUEST 


LEAVE 
AIR CONTROL CHECK 


PORT DUTY STATION 


:Alphanumeric ] Category of the 
Air Controller. 
(if the person 1s, 
"N" if he is not). 
:Alphanumeric l "Y" if he is Instructor, 
"N" if he is not. 
:Alphanumeric 12 ‘Person's Religion. 
:Alphanumeric 12 Person's Undergraduate 
Education. 
:Alphanumeric 25 _—* Foreign Languages 
spoken by the Person. 
:Alphanumeric 25 Person's Hobbies. 
-TRAINING 
object; MV 
(OJT EVALUATION 
object; MV 
-DEPENDENT 
object 
:PROMOTION 
object; MV 
‘FITNESS 
EVALUATION 
object 
‘DIVISION object 
‘DISCIPLINARY 
object; MV 


-ABANDON SHIP 


STATION object 


‘SPECIAL STATION 


object; MV 


“SPECIAL DUTY 


object; MV 


-REQUEST 


object; MV 


-LEAVE object; MV 
“AIR CONTROL 


CHECK object; MV 


-~PORT DUTY 


STATION object 
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DEPENDENTS OBJECT 
Dependent's Name 
Dependent's Address 


Dependent's Phone # 
Other Dependents' Name 


PERSON 
DISCIPLINARY OBJECT 
Offence # 


Offence Name 
Date of Offence 
Apology 
Punishment 

Start Date 

End Date 
Reporting Officer 


PERSON 
PROMOTION OBJECT 


Promotion Date 
Command Issued the Order 


Date of Issued Order. 
PERSON 


FITNESS EVALUATION OBJECT 


Reference Period 


Start Date 
End Date 


Grade 


:Alphanumeric 
:Alphanumeric 


:Alphanumeric 
:Alphanumeric 


-PERSON object 


:Alphanumeric 


:Alphanumeric 
:Date 

:-Memo 
:Alphanumeric 
:Date 

:Date 
:Alphanumeric 


-PERSON object 


:Date 
:Alphanumeric 


:Date 
:-PERSON object 


‘Alphanumeric 


-Date 
‘Date 


:Alphanumeric 


7) 


ZS 


2 


10 
30 


20 


100 


Z 


Name of Person's 
Closest Dependent. 
Address of the 
Dependent. 
Dependent's Phone #. 
Names of Other 
Possible Dependents. 


Number of the 
Offence:"mmdd". 
Name of the Offence. 
mm/dd/yy 

Person's Apology. 
Imposed Punishment. 
mm/dd/yy 

mm/dd/yy 

Name of the 
Reporting Officer. 


mm/dd/yy 

Higher Command 

Issued the Promotion Order. 
mm/dd/yy 


Period that Fitness 
Evaluation 1s referred to: 
(mmyy). 

mm/dd/yy 

mm/dd/yy 


"P":1f Pass; 
"F'sf Fail. 


Comments 
PERSON 


OJT EVALUATION OBJECT 
Start Date 

End Date 

Grade 


Comments 
Station Duty of Qualification 


Officer Performed the 
Qualification 


PERSON 
TRAINING OBJECT 
School 


Date 
Degree/Diploma 


No. of Participants 


Grade 


Order of Success 
among Participants 


Comments 
PERSON 
AIR CONTROL CHECK OBJECT 


Date 
Time 


Type of Aircraft 


‘Memo 
-PERSON object 


:Date 

:Date 
:Alphanumeric 
:Memo 
:Alphanumeric 
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APPENDIX G: APPLICATION REPORTS 


mm/dd/yy Personal Information Card 


Personal ID #: AAAAAAAAAA Division Name: AAAAAAAAAAAAAAA 
Port Duty Station Name: AAAAAAAAAAAAAAA 

Last Name : AAAAAAAAAAAAAAA 

First Name: AAAAAAAAAAAAAAA 


Rank: A Rate: AAAAAAA Current Posision: AAAAAAAAAAAAAAA 
Specialty: AAAAAAAAAAAAAAA Berthing: AAAAAAAAAA 


Abandon Ship Station #: AAA Location: AAAAAAAAAA 


1/3 Crew Division System: A 
1/2 Crew Division System: A 
Session: A 


Special Station Type: AAA 

Title: AAAAAAAAAAAAAAAAAAAA 

Duty: AAAAAAAAAAAAAAAAAAAA 

Equipment: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Gathering Position: AAAAAAAAAA _ 
Type of Special Duty: AAAAAAAAAAAAAAAAAAAA 

Duty Title: AAAAAAAAAAAAAAA 

Duty Instructions: AAAA : 
Equipment/Gun+Amo: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Gathering Position: AAAAAAAAAA 





Personal Information Card Format 


mm/dd/yy Personnel Fitness Evaluation Report 


Personal ID #: AAAAAAAAAA Rank:A Reference Period:AAAA 


Last Name : AAAAAAAAAAAAAAA Rate :AAAAAAA Grade:A 
First Name: AAAAAAAAAAAAAAA Specialty: AAAAAAAAAAAAAAA 
Date of Birth: mm/dd/yy 
Start Date: mm/dd/yy End Date: mm/dd/yy 
Comments: : 





Fitness Evaluation Report Forrmat 
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CiGucex’ seSvpecval..xXeport 


Personal 


Specialty: AAAAAAAAAAAAAAA 


Nearest Police station & phone Nr. 





Officer's Special Report Format 


mm/dd/yy Officers’ Monthly Report 





Person ID Rank Rate Last Name Current Pos. Address 
AAAAAADAAA A AAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA 
First Name Previous Pos. 

Specialty AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA 
AAAAAAAAAAAAA Date of Change 
mm/dd/yy 


ee a 


Officer's Monthly Report Format 


Petty Officers’ Monthly Report 


Last Name Rank Rate Person ID Current Pos. Address 
AAAAAAAAAAAAAAA A AAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA 
Tirst Name Specialty Near Police Station 
AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA 





Petty Officer's Monthly Report Format 
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mm/dd/vy 1/2 Craw Division System 


Dace 3 
Division Person iD Last Name first Name Rank Rate SDeCC Mauna 
A AAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAA A AAAAAAA AAAAAAAAAAAAAA 


1/2 Crew Division System Report Format 


mm/dd/vy 1/3 Crew Division System Page 3 
Diy.sion Pesson TD Last Name First Name Rank Rate Specialty 
A AAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAA A AAAAAAA AAAAAAAAAAAAAA 


1/3 Crew Division System Report Format 


XO’s Daily Division System Reporc 


ixst Name Rank Rate 





XO Daily Session Division System Report Format 
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mm/dd/yy Alert Station Report 


Last/First Name Rank Rate Dav. : 
A AAAAAAA 1/3:A tecation 
AAAAAAAAAAAAAAA Specialty 2 A AAAAAAASAA 
AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA 
Berwhinge : AAAAAAAAAA 





Alert Station Report Format 


mm/dd/yy Special Station Report 


Last/First Name Rank Rate pay: Title | 

A AAAAAAA 1/3:A AAAAAAAAAAAAAAAAAAAA Locat2on 
AAAAAAAAAAAAAAA Specialty ern Duty AAAAAAAAAA 
AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA 


Berthing: AAAAAAAAAA 
Equipment: AAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAAAAAAAAAA 





Special Station Report Format 


im. 20/ YV Abamcdon Ship Stations Page 9 
Sieageson, +  LOCAC.On Rescue Vessel Cap/tv Last+First Name Rank Rate 
AAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAA 999999 AAAAAAAAAAAAAAA A AAAAAAA 
AAAAAAAAAAAAABA 


Abandon Ship Station Report Format 
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mm/dd/yv Personal Information 300K , RECORD Pace 9 


Hull #: AAAAA Ship’s Name: AAAAAAAAAAAAAAA Ship’s Class: AAAAAAAAAAAAAAA 


Department Name: AAAAAAAAAAAAAAA Division Name: AAAAAAAAAAAAAAA 
Personal ID #: AAAAAAAAAA Last/First Name: AAAAAAAAAAAAAAA, AAAAAAAAAAAAAAA 

Rank: A Rate: AAAAAAA Specialty: AAAAAAAAAAAAAAA Date of Birth:dd/mm/yy 
ivisicn Name: AAAAAAAAAAAAAAA Port Duty Station Name: AAAAAAAAAAAAAAA 

Abandon Ship Station #: AAA 

Current Posision: AAAAAAAAAAAAAAA 

Drevious Position: AAAAAAAAAAAAAAA Date of Change: mm/dd/yy 


1/3 Crew Division System: A 
1/2 Crew Division System: A 
Session: A 


Address: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Near Police st. & phone #: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAA 
Religion: AAAAAAAAAAAA Hobbies: AAAAAAAAAAAAAAAAAAAAAAAAA 

Ecucation: AAAAAAAAAAAA Foreign Languages: AAAAAAAAAAAAAAAAAAAAAAAAA 


Schooi: AAAAAAAAAAAAAAA Date: mm/dd/yy 
Degree/Diploma: AAAAAAAAAAAAAAAAAAAA 
Comments: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA 


Premotion Date: mm/dd/yy 
Command issued the Order: AAAAAAAAAA 
Dace of Issued Order: mm/dd/yy 


Type of Leave: AAAAAAAAAAAAAAA 
Date Starcs: mm/dd/yy Date Ends: mm/dd/yy No. of Days: AA 
comments-1l: 


Oflence #: AAAA Offence Name: AAAAAAAAAAAAAAAAAAAA 
Date of Offence: mm/dd/yy Punishment: AAA 
Type cz Duty: AAAAAAAAAAAAAAAAAAAA Duty Title: AAAAAAAAAAAAAAA 
SUSY <nScCmUGEens : 





Personal Information BOOK / RECORD 


NN (Sea, Air Control Monthly Reporte Page 9 


ee 


ame: AAAAAAAAAAAAAAA First Name : AAAAAAAAAAAAAAA 
A Rate: AAAAAAA Specraltv: AAAAAAAAAAAAAAA 
Seer >. Category: A InStYuccsYy Bear eens- crc. ee 


Time: AAAA AAAAAAAAAA Type of Controls A Duration of Commie uyemme 
-cmmencts: BA AAAL aye avs y- i a ave aya A NAAAS AD a AAD AKA 


Air Control Monthly Report Format 
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meee / VY Sa: ers’ Moncnly Reper= 


son ID Adadres 
aes anche AAAAAAAAAAAA ALA 
Scecialty Near Poli Stacccn 





Sailor's Monthly Report Format 


Se- liersiepunashmenseMenthnby Report 


Last Name C=: Date 
dd/mm/yvy 


First Name | 
Punisnment: 





Satlor's Punishment Monthly Report Format 
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APPENDIX H: SYSTEM'S PROGRAM AND CODE 


A. PART ONE: DOCUMENTATION OF MENU STRUCTURE 


SPAS - Shipboard Personnel Administration System 


Menu Tree 
Documentation of Menu Structure 


MAIN 

F PERSONNEL SUBSYSTEM _ Enter All Personal Data to the System 

| PROCESS CREWMEMBER DATA Enters Crewmember Data to the System 

PROCESS DEPENDENT DATA Enters Crewmembers' Dependent Data to the System 

PROCESS DISCIPLINARY DATA Enters Crewmembers' Disciplinary Data to the System 

PROCESS EVALUATION DATA Enters Crewmembers' Evaluation Data 

E PROCESS OJT EVALUATION DATA Enters Crewmembers' OJT Evaluation Data 
PROCESS FITNESS EVALUATION DATA Enters Crewmembers' Fitness Data 


| 


i MAINTAIN PERSON DATA Updates all Personnel Data 
UPDATE AIR CONTROL DATA Keeps Track of Air Control Data 
UPDATE PROMOTION DATA Updates Personnel Promotion Data 
—— UPDATE CREWMEMBER DATA Updates Crewmembers' Personal Data 
| ADD DATA Adds Crewmember Data 
: MODIFY DATA Modifies Crewmember Data 








| 
—— DELETE DATA __ Deletes Crewmember Data 


-— UPDATE DEPENDENT DATA Updates Crewmembers' Dependent Data 
aa ADD DATA Adds Dependents Data 
_— MODIFY DATA Modifies Dependents Data 

| DELETE DATA Deletes Dependents Data 
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UPDATE DISCIPLINARY DATA Updates Crewmembers' Disciplinary Data 
ADD DATA Adds Disciplinary Data 
MODIFY DATA Modifies Disciplinary Data 
DELETE DATA Deletes Disciplinary Data 
UPDATE EVALUATION DATA Updates Crewmembers' Evaluation Data 
ADD DATA Adds Evaluation Data 
MODIFY DATA Modifies Evaluation Data 
DELETE DATA Deletes Evaluation Data 
REQUEST SUBSYSTEM _ Handle Personnel Requests 
_— SPECIAL REQUEST Enters the System Crewmembers' Special Requests 
PROCESS LEAVE REQUEST Enters the System Crewmembers' Leave Requests 
REPORT SUBSYSTEM ~ Generates All the Reports 
ANSWER SPECIFIED QUERIES Answer Queries 
QUERY PERSON AND DEPENDENT Query Crewmember and his Dependent Data 


| QUERY PERSON AND SPECIAL STATION Query Crewmember and his Special Station Data 
QUERY PERSON AND DIVISION SYSTEM Query Crewmember and his Division Data 


QUERY PERSON,TRAINING,EVALUATION Query Crewmember's Training and Evaluation Data 


— PERSON,REQUEST,LEAVE,OJT,DISCIPL Query Crewmember and his Request,Leave, OJT 
Evaluation and Disciplinary 


| 
} 
= PRODUCE INTERNAL REPORTS Produce Reports for Ship's Use 
| '— PERSONAL INFORMATION CARD Produce Personal Information Card 
: = PERSONAL INFORMATION BOOK Produce Personal Information Book 
| ~ FITNESS EVALUATION REPORT Produce Crewmembers' Fitness Evaluation Report 
a DIVISION SYSTEM REPORT Produce Division Systems Reports 

—— 1/3 SYSTEM Produce 1/3 Crew Division System Report 

- 1/2 SYSTEM _ Produce 1/2 Crew Division System Report 

oe SESSION SYSTEM Produce Session Division System Report 
Ss SPECIAL DUTY STATION REPORT Produce Special Stations Reports 


‘" ALERT STATION Produce Alert Station Report 
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MOOR-ANCHO-TOW STATION Produce Ship's Maneuvers Station Report 
ABANDON SHIP STATION Produce Abandon Ship Station Report 
PRODUCE EXTERNAL REPORTS Produce Reports for Higher Commands 


AIR CONTROLLER MONTHLY REPORT Produce A/C Monthly Report 
OFFICER SPECIAL REPORT Produce Officers' Special Report 
OFFICER MONTHLY REPORT Produce Officers' Monthly Report 
PETTY OFFICER MONTHLY REPORT Produce Petty Officers' Monthly Report 
| SAILOR MONTHLY REPORT Produce Sailors' Monthly Report 
| SAILOR PUNISHMENT MONTHLY REPORT Produce Sailors’ Punishment Monthly Report 
= SEXIT Exit the System 
EXIT TO PARADOX _ Exit this Application but stays in PARADOX 
<Separator> 


EXIT TO DOS Exits PARADOX and Goes to DOS 
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B. PART TWO: DOCUMENTATION OF ACTION MENU 


SPAS - Shipboard Personnel Administration System 


Edit Session: SNII1A 


Mode: __ DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: PERSON 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Enters the System Personal Data 


Edit Session: SN11B 
Mode: _DataEntry 
Passwords: As Needed 
Prompt: 
Tables Declared: | 
Table 1: PROMOTIO- 


Initial View: Form 
Allowed Views: Form 


Use Form: 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Enters the System Person's Promotion Data 


Edit Session: SN11C 


Mode: DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: PERSTATN 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Ins, Edit 

On Tablelist: 

Prompt: Assigns Person to Special Stations 


Edit Session: SN11D 
Mode: DataEntry 
Passwords: As Needed 8 
Prompt: 
Tables Declared: 1 
Table 1: PERSDUTY 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 

Modes: Ins,Edit 

On Tablelist: 

Prompt: Assigns Person to Special Duties 


Edit Session: SN12 
Mode DataEntry 
Passwords: As Needed 
Prompt. 


Tables Declared: 1 


Table 1: DEPENDEN 
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Initial View: Form 
Allowed Views: Form 
Use Form: ] 
Modes: Ins, Edit 
On Tablelist: 
Prompt: Enters the System Person's Dependent Data 


Edit Session: SN124_ 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 
Tables Declared: | 
Table 1: FITNESS 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 

Modes: Ins, Edit 

On Tablelist: 

Prompt: Enter to the System All Personnel Fitness Evaluation Data 


Edit Session: SN13 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 
Tables Declared: 1 
Table 1: DESCIPLN 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 
Modes: Ins,Edit 
On Tablelist: 
Prompt: 
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Edit Session: SN14]1 


Mode: DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: OJT-EVAL 


Initial View: Form 

Allowed Views: Form 

Use Form: l 

Modes: Ins, Edit 

On Tablelist: 

Prompt: Enters the System Personal OJT Evaluation Data 


Edit Session: SN151 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 
Tables Declared: 1 
Table 1: AIR-CTRL 
Initial View: Form 
Allowed Views: Form 
Use Form: ] 
Modes: Ins,Edit 
On Tablelist: 
Prompt: Enters the System Air Control Data 
Edit Session: SN152 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 
Tables Declared: } 
Table 1: PROMOTIO 


Initial View: Form 
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Allowed Views: Form 


Use Form: ] 

Modes: Ins, Update 

On Tablelist: 

Prompt: Updates Personnel Promotion Data 


Edit Session: SN1531 


Mode: _ DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: PERSON 


Initial View: Form 

Allowed Views: Form 

Use Form: l 

Modes: Ins, Update 

On Tablelist: 

Prompt: Adds Crewmember Data 


Edit Session: SN1532 


Mode: Edit 
Passwords: As Needed 
Prompt: 


Tables Declared: ] 


Table 1: PERSON 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 

Modes: Edit 

On Tablelist: 

Prompt: Modifies Crewmember Data 

Edit Session: SN1533 

Mode: Edit 
Passwords: As Needed 
Prompt: 
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Tables Declared: 1 
Table 1: PERSON 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 

Modes: Del, Edit 

On Tablelist: 

Prompt: Deletes Crewmember Data 


Edit Session: SN154]1 


Mode: DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: DEPENDEN 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Ins,Update 

On Tablelist: 

Prompt: Adds Dependent Data 


Edit Session: SN1542 


Mode: Edit 
Passwords: As Needed 
Prompt: : 


Tables Declared: } 
Table 1: DEPENDEN 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Edit 

On Tablelist: 

Prompt: Modifies Dependent Data 


lad 


Edit Session: SN1543 


Mode: Edit 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: DEPENDEN 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Del, Edit 

On Tablelist: 

Prompt: Deletes Dependent Data 


Edit Session: SN1551 


Mode: DataEntry 
Passwords: As Needed 
Prompt: 

Tables Declared: 1 
Table 1: DESCIPLN 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 
Modes: Ins,Update 
On Tablelist: 


Prompt: Adds Disciplinary Data 


Edit Session: SN1552 


Mode: Edit 
Passwords: As Needed 
Prompt: 
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Tables Declared: 1 
Table 1: DESCIPLN 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Edit 

On Tablelist: 

Prompt: Modifies Disciplinary Data 


Edit Session: SN1553 


Mode: Edit 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: DESCIPLN 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Del, Edit 

On Tablelist: 

Prompt: Deletes Disciplinary Data 


Edit Session: SN1561 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: OJT-EVAL 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Ins,Update 

On Tablelist: 

Prompt: Adds OJT Evaluation Data 
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Edit Session: SN1562 


Mode: Edit 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 
Table 1: OJT-EVAL 


Initial View: Form 

Allowed Views: Form 

Use Form: ] 

Modes: Edit 

On Tablelist: 

Prompt: Modifies OJT Evaluation Data 


Edit Session: SN1563 


Mode: Edit 
Passwords: As Needed 
Prompt: 


Tables Declared: 1 


Table 1: OJT-EVAL 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 

Modes: Del, Edit 

On Tablelist: 

Prompt: Deletes OJT Evaluation Data 


Edit Session: SN2] 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 


Tables Declared: ] 


zs 


Table 1: REQUEST 


Initial View: Form 
Allowed Views: Form 


Use Form: ] 
Modes: Ins,Edit 
On Tablelist: 
Prompt: 


Edit Session: SN22 
Mode: DataEntry 
Passwords: As Needed 
Prompt: 
Tables Declared: 1 
Table 1: LEAVE 


Initial View: Form 
Allowed Views: Form 


Use Form: l 
Modes: Ins, Edit 
On Tablelist: 
Prompt: 


Edit Session: SN31] 
Mode: DataEntry 
Passwords: As Needed 
Prompt: Enter the Crewmember Last/First Name 
Tables Declared: | 
Table 1: AD-HOC 


Initial View: Form 
Allowed Views: Form 


Use Form: F 
Modes: Ins,Edit 
On Tablelist: 
Prompt: 


Edit Session: SN312 
Mode: DataEntry 
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Passwords: As Needed 
Prompt: Enter the Crewmember.Last/First Name 


Tables Declared: 1 
Table 1: AD-HOC 


Initial View: Form 
Allowed Views: Form 
Use Form: F 
Modes: Ins,Edit 
On Tablelist: 

Prompt: 


Edit Session: SN313 


Mode:  DataEntry 
Passwords: As Needed 
Prompt: Enter the Crewmember Last/First Name 


Tables Declared: 1 
Table 1: AD-HOC 


Initial View: Form 
Allowed Views: Form 
Use Form: F 
Modes: Ins, Edit 
On Tablelist: 

Prompt: 


Edit Session: SN314 
Mode: _DataEntry 
Passwords: As Needed 
Prompt: Enter the Crewmember Last/First Name 
Tables Declared: 1 
Table 1: AD-HOC 


Initial View: Form 
Allowed Views: Form 
Use Form: F 
Modes: Ins, Edit 
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On Tablelist: 
Prompt: 


Edit Session: SN315 


Mode: DataEntry 
Passwords: As Needed 
Prompt: Enter the Crewmember Last/First Name 


Tables Declared: 1 
Table 1: AD-HOC 


Initial View: Form 
Allowed Views: Form 
Use Form: F 
Modes: Ins, Edit 
On Tablelist: 

Prompt: 


Multiple Actions: MA1]] 


Actions Called: 


1) Edit Session: SNIIA 
2) Edit Session: SN11B 
3) Edit Session: SN11C 
4) Edit Session: SN11D 


[X] Quit 1f Action fails 


Multiple Actions: MA311 


Acuons Called: 


1) Edit Session: SN31] 
2) Play a Script: Adhoc]l 
3) Report Print: PRN31] 


4) Play a Script: Empty 


(X] Quit if Action fails 
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Actions Called: 


1) Edit Session: 
2) Play a Script: 
3) Report Print: 
4) Play a Script: 


[X] Quit if Action fails 


Actions Called: 


1) Edit Session: 
2) Play a Script: 
3) Report Print: 
4) Play a Script: 


[X] Quit if Action fails 


Actions Called: 


1) Edit Session: 
2) Play a Script: 
3) Report Print: 
4) Play a Script: 


[X] Quit if Action fails 


Actions Called: 


1) Edit Session: 
2) Play a Script: 
3) Report Print: 
4) Play a Script: 


Multiple Actions: MA312 


SN312 
Adhoc2 
PRN312 


Empty 


Multiple Actions: MA313 


SN3 13 
Adhoc3 
PRN313 


Empty 


Multiple Actions: MA314 


SN314 
Adhoc4 
PRN314 


Empty 


Multiple Actions: MA315 


SN315 
AdhocS5 
PRN315 


Empty 


lz 


[X] Quit if Action fails 


Multiple Actions: MA316 


Actions Called: 


1) Play a Script: Q321 
2) Report Print: PRN321 


[X] Quit if Action fails 


Multiple Actions: MA322 


Actions Called: 


1) Play a Script: Q322 
2) Report Print: PRN322 


[X] Quit if Action fails 


Multiple Actions: MA323 


Actions Called: 


1) Play a Script: Q323 
2) Report Print: PRN323 


[X] Quit if Action fails 


Multiple Actions: MA324A 


Actions Called: 


1) Play a Script: Q324a 
2) Report Print: PRN324A 
[X] Quit if Action fails 


Multiple Actions: MA324B 
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Actions Called: 


1) Play a Script: 
2) Report Print: 


[X] Quit if Action fails 


Actions Called: 


1) Play a Script: 
2) Report Print: 


[X] Quit if Action fails 


Actions Called: 


1) Play a Script: 
2) Report Print: 


[X] Quit if Action fails 


Actions Called: 


1) Play a Script: 
2) Report Print: 


[X]} Quit if Action fails 


Actions Called: 
1) Play a Script: 
2) Report Print: 


[X] Quit if Action fails 


Q324b 
PRN324B 


Multiple Actions: MA324C 


Q324c 
PRN324C 


Multiple Actions: MA325A 


Q325a 
PRN325A 


Multiple Actions: MA325B 


Q325b 
PRN325B 


Multiple Actions: MA325C 


@325c 
PRN325C 


13) 


Multiple Actions: MA331 


Actions Called: 


1) Play a Script: Q331 
2) Report Print: PRN331 


[X] Quit if Action fails 
Multiple Actions: MA332 
Actions Called: 


1) Play a Script: Q332 
2) Report Print: PRN332 


[X] Quit if Action fails 


Multiple Actions: MA333 


Actions Called: 


1) Play a Script: Q333 
2) Report Print: PRN333 


[X] Quit if Action fails 


Multiple Actions: MA334 


Actions Called: 


1) Play a Script: Q334 
2) Report Print: PRN334 


[X] Quit if Action fails 


Multiple Actions: MA335 
Actions Called: 


1) Play a Script: 0335 
2) Report Print: PRN335 
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[X] Quit if Action fails 


Multiple Actions: MA336 


Actions Called: 


1) Play a Script: Q336 
2) Report Print: PRN336 


[X] Quit if Action fails 


Report Print: PRN311] 


Table: ANSWER 


Report #: R 
Use Data From: Listed Table 
Output Devices: Screen 
Display Working Message: Yes 
Working Message: Here 1s the Requested Data 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN312 


Table ANSWER 


Report #. R 
Use Data From: Listed Table 
Output Devices: Screen 
Display Working Message: Yes 
Working Message: Here 1s the Requested Data 
Printer Port: Default 
Page Break: Default 
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Prefix String: None 


Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN313 


Table: ANSWER 


Report #: R 
Use Data From: Listed Table 
Output Devices: Screen 
Display Working Message: Yes 
Working Message: Here is the Requested Data 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN314 


Table: ANSWER 


Report #: R 
Use Data From: Listed Table 
Output Devices: Screen 
Display Working Message: Yes 
Working Message: Here is the Requested Data 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN315 


Table: ANSWER 
Report #: R 
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Use Data From: Listed Table 


Output Devices: Screen 

Display Working Message: Yes 

Working Message: Here is the Requested Data 

Printer Port: Default 

Page Break: Default 

Prefix String: None 

Suffix String: None 

Setup Proc: None 

Cleanup Proc: None 

Report Print: PRN321 

Table: 1321 
Report #: 1 

Use Data From: Listed Table 

Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Personal Information Card ... 

Printer Port: Default 

Page Break: Default 

Prefix String: None 

Suffix String: None 

Setup Proc: None 

Cleanup Proc: None 

Report Print: PRN322 

ables 17322 
Report #: | 

Use Data From: Listed Table 

Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Personal Info Book/Record ... 

Printer Port: Default 

Page Break: Default 

Prefix String: None 

Suffix String: None 

Setup Proc: None 

Cleanup Proc: None 
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Report Print: PRN323 


Table: 1323 

Report #: 1] 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Personnel Fitness Evaluation Report.. 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN324A 


Table: T324A 


Report #: 1] 
Use Data From: Listed Table = 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: 1/3 Crew Division System Report ... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN324B 
Table: T324B 


Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: 1/2 Crew Division System Report ... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
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Cleanup Proc: None 


Report Print: PRN324C 


Table: T324C 


Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Session Division Report ... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN325A 


Table: T325A 


Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Alert Station Report ... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: "None 
Setup Proc: None 
Cleanup Proc: None 


Report Print: PRN325B 


Table: T325B 


Report #: ] 
Use Data From: Listed Table 
Output Devices: Screen, Printer 


Display Working Message: Yes 
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Working Message: 
Printer Port: 

Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Table: T325C 
Report #: 1 


Use Data From: 
Output Devices: 


Special Station Report ... 
Default 
Default 
None 
None 
None 
None 


Report Print: PRN325C 


Listed Table 
Screen, Printer 


Display Working Message: Yes 


Working Message: 
Printer Port: 

Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Table: T1331 
Report #: 1 


Use Data From: 
Output Devices: 


Abandon Ship Station Report ... 
Default 
Default 
None 
None 
None 
None 


Report Print: PRN331] 


Listed Table 
Screen, Printer 


Display Working Message: Yes 


Working Message: 
Printer Port: 

Page Break: 
Prefix String: 
Suffix String: 
Setup Proc: 
Cleanup Proc: 


Table: 1332 
Report #: 1} 


Air Control Monthly Report ... 
Default 
Default 
None 
None 
None 
None 


Report Print: PRN332 
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Use Data From: Listed Table 


Output Devices: Screen, Printer 

Display Working Message: Yes 

Working Message: Officer Special Report ... 
Printer Port: Default 

Page Break: Default 

Prefix String: None 

Suffix String: None 

Setup Proc: None 

Cleanup Proc: None 


Report Pint: PRN333 


Table: 1333 
Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Officers' Monthly Report ... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 
Report Print: PRN334 
Table: 1334 
Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Petty Officers’ Monthly Report ... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 
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Report Print: PRN335 


Table: 1335 
Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Sailors’ Monthly Report... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 
Report Print; PRN336 
Table: 1336 
Report #: 1 
Use Data From: Listed Table 
Output Devices: Screen, Printer 
Display Working Message: Yes 
Working Message: Sailors’ Punishment Monthly Report... 
Printer Port: Default 
Page Break: Default 
Prefix String: None 
Suffix String: None 
Setup Proc: None 
Cleanup Proc: None 
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C. PART THREE: DOCUMENTATION OF CROSS-REFERENCE MENU 


SPAS - Shipboard Personnel Administration System 


Cross Reference 


Action Objects & Paradox Objects in Use 


Objects in the Menu & Object Tables: Referenced by: 


Object Type 


Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Exit Paradox 
Form 


Object Name 


SNIIA 
SNIIB 
SNIIC 
SN11D 
SN12 
SN124 
SN13 
SN141 
SN151 
SN152 
SN1531 
SN1532 
SN153 
SN1541 
SN1542 
SN1543 
SN1551 
SN1552 
SN1553 
SN1561 
SN1562 
SN1563 
SN21 
SN22 
SN311 
SN312 
SN313 
SN314 
SN315 


AD-HOC.F 


Object Type 


Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 


Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 
Menu 


Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 


Menu 

Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 


Object Name 


MAI!1 
MA!11 
MAI!11 
MAI11 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
CFG\SPAS 
MA311 
MA312 
MA313 
MA314 
MA315 
CFG\SPAS 
SN311 
SN312 
SN313 
SN314 
SN315 
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Form AIR-CTRL.F1 Edit Session SN151 
Form DEPENDEN.-F1 Edit Session SN12 
Edit Session SN1541 
Edit Session SN1542 
Edit Session SN1543 
Form DESCIPLN.F1 Edit Session SN13 
Edit Session SN155] 
Edit Session SN1552 
Edit Session SN1553 
Form  FITNESS.F1 Edit Session SN124 
Form LEAVE.F1 Edit Session SN22 
Form OJT-EVAL.F1 Edit Session SN141 
Edit Session SN1561 
Edit Session SN1562 
Edit Session SN1563 
Form PERSDUTY.F1 Edit Session SN11D 
Form PERSON.F1 Edit Session SNI1A 
Edit Session SN1531 
Edit Session SN1532 
Edit Session SN1533 
Form PERSTATN.F1 Edit Session SNI1C 
Form PROMOTIO-F1 Edit Session SN11B 
Edit Session §N152 
Form REQUEST.F1 Edit Session SN21 
Multiple Actions MAI11 Menu CFG\SPAS 
Multiple Actions MA311 Menu CFG\SPAS 
Multiple Actions MA312 Menu CFG\SPAS 
Multiple Actions MA313 Menu CFG\SPAS 
Multiple Actions MA314 Menu CFG\SPAS 
Multiple Actions MA315 Menu CFG\SPAS 
Multiple Actions MA321 Menu CFG\SPAS 
Multiple Actions MA322 Menu CFG\SPAS 
Multiple Actions MA323 Menu CFG\SPAS 
Multiple Actions MA324A Menu CFG\SPAS 
Multiple Actions MA324B Menu CFG\SPAS 
Multiple Actions MA324C Menu CFG\SPAS 
Multiple Actions MA325A Menu CFG\SPAS 
Multiple Actions MA325B Menu CFG\SPAS 
Multiple Actions MA325C Menu CFG\SPAS 
Multiple Actions MA331 Menu CFG\SPAS 
Multiple Actions MA332 Menu CFG\SPAS 
Multiple Actions MA333 Menu CFG\SPAS 
Multiple Actions MA334 Menu CFG\SPAS 
Multiple Actions MA335 Menu CFG\SPAS 
Multiple Actions MA336 Menu CFG\SPAS 


Play a Script ADHOC] 
Play a Script ADHOC2 


MA311 
MA312 


Multiple Actions 
Multiple Actions 
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Play a Script 
Play a Script 
Play a Script 
Play a Script 


Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Play a Script 
Procedure 


ADHOC3 
ADHOC4 
ADHOC5 


EMPTY 


Q321 
Q322 
Q323 
Q324A 
Q324B 
Q324C 
Q325A 
Q325B 
Q325C 
Q331 
Q332 
Q333 
Q334 
Q335 
Q336 


Quit to Paradox 


Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Application 
Menu 


MA313 
MA314 
MA315 
MA311 
MA312 
MA313 
MA314 
MA315 
MA3721 
MA322 
MA323 
MA324A 
MA324B 
MA324C 
MA325A 
MA325B 
MA325C 
MA331 
MA332 
MA333 
MA334 
MA335 
MA336 


SPAS 
CFG\SPAS 





Report 


Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 
Report 


Report Print 
Report Print 


ANSWER.R 


T321.R1 
T322.R] 
T323.R]1 
T324A.R] 
T324B.R] 
T324C.R] 
T325A.R] 
T325B.R] 
T325C.R] 
T331.R1 
T332.R] 
T333.R] 
T334.R] 
T335.R] 
T336.R] 
PRN31 1 
PRN312 


Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 


Multiple Actions 
Multiple Actions 


PRN311 
PRN3 12 
PRN3 13 
PRN314 
PRN315 
PRN321 
PRN322 
PRN323 
PRN324A 
PRN324B 
PRN324C 
PRN325A 
PRN325B 
PRN325C 
PRN33 1 
PRN332 
PRN333 
PRN334 
PRN335 
PRN336 
MA311 
MA312 
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Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Table 


Table 
Table 


Table 


Table 


Table 
Table 
Table 


Table 
Table 


PRN313 
PRN314 
PRN315 
PRN32] 
PRN322 
PRN323 
PRN324A 
PRN324B 
PRN324C 
PRN325A 
PRN325B 
PRN325C 


Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 


MA313 
MA314 
MA315 
MA321 
MA322 
MA323 
MA324A 
MA324B 
MA324C 
MA325A 
MA325B 
MA325C 


PRN33 1 
PRN332 
PRN333 
PRN334 
PRN335 
PRN336 


AD-HOC 


AIR-CTRL 
ANSWER 


DEPENDEN 


DESCIPLN 


FITNESS 
LEAVE 
OJT-EVAL 


PERSDUTY 
PERSON 


Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 
Multiple Actions 


Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 


MA331 
MA332 
MA333 
MA334 
MA335 
MA336 
SN311 
SN312 
SN313 

SN3 14 
SN315 
SN151 
PRN311 
PRN312 
PRN3 13 
PRN314 
PRN315 
SN12 
SN1541 
SN1542 
SN1543 
SN13 
SN1551 
SN1552 
SN1553 
SN124 
SN22 
SN141 
SN1561 
SN1562 
SN1563 
SN11D 
SNIIA 
SN1531 
SN1532 
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Table 
Table 


Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 
Table 


PERSTATN 
PROMOTIO 


REQUEST 
732] 
T322 
7323 
T324A 
T324B 
T324C 
T325A 
T325B 
T325C 
1 
1332 
Tiga 
T334 
T335 
T336 


Edit Session 
Edit Session 
Edit Session 
Edit Session 
Edit Session 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 
Report Print 


SN1533 
SNIIC 
SNIIB 
SN152 
SN2] 
PRN321 
PRN322 
PRN323 
PRN324A 
PRN324B 
PRN324C 
PRN325A 
PRN325B 
PRN325C 
PRN331 
PRN332 
PRN333 
PRN334 
PRN335 
PRN336 
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APPENDIX I: PROCEDURES FOR INSTALLING AND OPERATING SPAS 


A. Installation Procedure 
To run any Paradox application, Paradox itself must be installed. To install Paradox 
the user has to run the Paradox installation program. Instructions for installing Paradox 


can be found in Paradox manuals. 


B. Setting up the SPAS application 

After installing Paradox you need to setup the SPAS application. This can be done 
in several ways. The suggested method from the DOS environment 1s described on the 
following page. Your SPAS application disk includes all required files and has one 
directory and two subdirectories. Figure 16 shows how the files are organized in the 


diskette. 


CFG WORKSHOP 
Subdirectory Subdirectory 





Figure 16:SPAS application disk hierarchy 
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From the DOS environment, insert the application disk into the floppy drive, and 
perform the following steps: 
1. Make sure that you are at the C:\PDOX40>. (If you are at the C:\>, type cd 
PDOX40 and then hit enter). 
2. Type md SPAS (creates the SPAS directory) 
3. Type cd SPAS (puts you in SPAS directory and displays the C:\PDOX40\SPAS> 
prompt) 
4. Type md CFG (creates the CFG directory) 
5. Type md WORKSHOP (creates the WORKSHOP directory) 
6. Type copy a:\spas\*.* c: (copies the files to hard disk) 
7. Type cd CFG (puts you in the CFG directory and displays the 
C:\PDOX40\SPAS\CFG> prompt) 
8. Type copy a:\spas\cfg\*.* c: (copies the files to hard disk) 
9 Type cd.. (you are at the C:\PDOX40\SPAS> prompt) 
10. Type cd WORKSHOP (puts you in the WORKSHOP directory and displays the 
C:\PDOX40\SPAS\WORKSHOP?> prompt) 
11. Type copy a:\spas\workshop\*.* c: (copies the files to hard disk) 
Now you have everything copied on your hard disk drive, and your application is 
ready to run. You can start running Paradox by typing "paradox" at the 


C:\PDOX40\SPAS> prompt. Figure 17 shows how your screen will look like. 
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Figure 17: Paradox screen 


C. Using the SPAS application 

To run the SPAS application in the Paradox environment, you have to select the 
application from the pull-down menu bar. Using the mouse, click on the top left most 
field of the pull-down menu bar (indicated by three horizontal lines), then click on 
"Utilities", and then click on "Workshop". The working desktop now is the Paradox 
workshop. On the new desktop, click on "Application", then on "Directory", type 
c:\pdox40\spas and hit enter,or click on OK. Now you are at the application workspace. 
Click again on "ParadoxEdit", "Scripts" and select "SPAS" from the scripts list. Finally 
click on "Play" and the SPAS application will be executed showing a screen that looks 


like figure 18. 
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The application has four main pull-down menus. Figure 18 shows the main 
The function of each menu is self descriptive. 
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Figure 18: SPAS screen 
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2. Help screens 
Help screens are included in SPAS and are designed to help the user follow 
the night steps for each procedure. In this way the user can respond correctly to data 
entry and updates and eliminate potential mistakes. 
3.  Pnnting outputs 
After performing a report operation from the report subsystem, there is a dialog box 
asking whether to print the results onto the screen, or to the printer. Choose the desired 


output media from this menu. 
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